Как выбрать базу данных

Выбираем базу данных

Опытный ли вы инженер-программист или студент, пишущий университетский проект, в какой-то момент вам нужно будет выбрать базу данных для ваших целей.

Если вы ранее уже использовали какую-то БД, вы можете просто сказать: “Я выберу эту базу, потому что знаком с ней”. Это вполне подходящее решение, когда производительность не критична для вашего проекта. В противном случае выбор неподходящей базы станет препятствием при расширении проекта. Исправить ошибку может быть довольно сложно. Даже если вы работаете в зрелом проекте, который использует конкретную БД, важно знать ее ограничения и понимать, когда стоит добавить базу другого типа к вашему стеку. Комбинирование нескольких баз данных довольно распространено.

Еще одна причина разобраться с базами данных и их свойствами: вопросы о БД очень распространены на собеседованиях. Когда вам будет нужна короткая шпаргалка, прокрутите в конец поста.

Реляционные базы данных

Эти базы состоят из связанных между собой таблиц. Каждая строка таблицы представляет собой запись. Почему такие базы называются реляционными? Потому, что они строятся на отношениях между объектами, описанными в БД.

Допустим, у вас есть таблица с информацией о студентах и таблица оценок курса (курс, оценка, идентификатор студента). Каждая строка с оценкой соотносится с записью о студенте. На диаграмме ниже значение в столбце Student ID указывает на строки в таблице Students по их значению в столбце ID .

Все данные из реляционных баз данных запрашиваются с помощью SQL-подобных языков, имеющих встроенную поддержку операции объединения. Реляционные базы позволяют индексировать столбцы для быстрых запросов. Из-за своей структурированной природы, схема реляционных баз данных определяется до ввода данных. Примеры таких баз:

• MySQL.
• PostgreSQL.
• Oracle.
• MS SQL Server.

NoSQL базы данных

В реляционных базах данных все структурировано по колонкам и столбцам. В свою очередь, в нереляционных базах нет общей структурированной схемы для записей. Большая часть NoSQL баз содержит JSON записи. Разные записи могут содержать разные поля.

Это семейство БД называется NoSQL (Not only SQL — не только SQL), так как многие NoSQL базы данных поддерживают SQL, но это не самый лучший вариант их использования. Cуществует 4 типа баз данных NoSQL.

Документные

Атомарной (неделимой) единицей таких БД является документ. Каждый документ — JSON, схема может различаться в разных документах и содержать разные поля. Документные БД позволяют индексировать некоторые поля документа для ускорения запросов на основе этих полей. Следовательно, во всех документах есть поля.

Использование

Поскольку различные записи независимы друг от друга (логически и структурно), эти базы данных поддерживают параллельные вычисления, что позволяет легко анализировать большой объём данных. Примеры:

• MongoDB
• CouchDB
• DocumentDB

Колоночные

Атомарная единица таких БД — колонка таблицы. Данные сохраняются столбец за столбцом, что делает колоночные запросы очень эффективными, и, поскольку данные в каждой колонке однородны, это позволяет лучше сжимать данные.

Использование

В тех случаях, когда удобно делать запросы к подмножеству столбцов (оно не обязательно должно быть одинаковым каждый раз!). Колоночные БД обрабатывают такие запросы очень быстро, так как читают только конкретные колонки (в то время как строчные БД должны читать строки полностью).

В науке о данных часто бывает, что каждая колонка представляет определенную характеристику. Как специалист по данным я часто тренирую свои модели на подмножествах характеристик и проверяю отношения между ними и оценками (корреляция, дисперсия, значимость). То же подходит и для логов— в них зачастую множество полей, но при каждом запросе используются только некоторые. Например:

• Cassandra.

Ключ-значение

В этих БД запросы только на основе ключа — вы запрашиваете ключ и получаете его значение.

Такие БД не поддерживают запросы между различными значениями записей, вроде такого: выбрать все записи, где город — Нью-Йорк.
Полезное свойство этих БД — поле времени жизни (Time-to-Live, TTL), в котором можно задать отдельно для каждой записи и состояния, когда их нужно удалить из БД.

Достоинства

Это очень быстрые БД. Во-первых, потому что используют уникальные ключи, во-вторых, потому что большинство БД типа ключ-значение хранят данные в оперативной памяти, что обеспечивает быстрый доступ к данным.

Недостатки

Необходимо определять уникальные ключи, хорошие идентификаторы, основанные на заранее известных вам данных. Зачастую они дороже, чем другие типы баз данных, так как используют оперативную память.

Использование

В основном используются для кэширования, потому что быстрые и не требуют сложных запросов. Поле времени жизни для кэширования также очень полезно. Такие БД могут использоваться для любых данных, которые требуют быстрых запросов и соответствуют формату ключ-значение. Примеры таких баз:

• Redis
• Memcached

Графовые

Содержат узлы, отображающие объекты, а также ребра, отображающие отношения между ними.

Использование
Созданы для работы с графовыми данными, такими как сети знаний или социальные сети. Примеры баз:

• Neo4j
• InfiniteGraph

Реляционные или документные?

Как вы уже догадались, универсального решения нет. Самые распространенные БД для регулярного использования — реляционные и документные. Давайте сравним их.

Рассуждение на тему, какую базу данных выбирать

Народная СУБД или «must have», есть практически на любом хостинге. Простая в установке, работает нормально без особых настроек. При должном подходе может гибко настраиваться под ваши нужды. Но есть и подводные камни, в некоторые случаях она будет тем самым узким горлышком и ваш проект будет тормозить, как бы вы не тюнинговали СУБД и структуру данных.
MySQL для вас, если:

— вы консерватор и не хотите вникать в настройки СУБД, просто поставили и работает (ну или на хостинге используете то, что дают);
— вы консерватор же, значит мыслите структурно, таблично. MySQL справится;
— в любом языке программирования, фреймворке, CMS, CMF и так далее и тому подобное — есть интеграция с MySQL.
— вы новичОк и вам нужна СУБД для управления структурными данными, желательно небольшими (до 1 — 2 гигабайт).

Минусы? Их есть и вам следует выбрать другую СУБД, если увидите важное.

— посредственная производительность. Действительно низкая, как не тюнингуй. даже кластер не поможет особо (его еще настроить надо, ага, те еще танцы с бубном). Речь о цифрах порядка 20 МБайт/сек. Из личного опыта, на SSD дисках при таком потоке MySQL упирался в свой предел, не справлялся и тормозил, причем сервис настраивался несколько лет, использовались оптимальные для нагрузки настройки. Из коробки конфигурацию, думаю будет еще меньше планку иметь;
— изменение структуры данных может быть довольно трудоемким процессом, особенно при большом количество связей между данными в разных таблицах и даже при простом добавлении полей;
— чувствительность к нестабильности сервера. Особенно это влияет при использовании XtraDB от Percona. Если неправильно завершить MySQL, можно настолько поломать таблицы и базы данных, что восстановить можно будет только из полного бекапа, конечно, если вы их регулярно делаете. И поверьте, это случается всегда в самый неожиданный момент. Есть инструменты, которые в несложных ситуациях помогут восстановить работоспособность, но они не панацея. В последних и актуальных версиях активно борются с этим, заявлена гораздо лучшая стабильность и надежность.

PostgreSQL

Своего рода мастодонт, очень старая и грамотная СУБД. Она почти как MySQL, только лучше. Но надо уметь готовить и настраивать. По мнение многих, очень стабильная СУБД, ее практически невозможно уронить, порушить таблицы как в MySQL. И это может быть для вас решающим фактором при выборе.

PostgreSQL для вас, если:

— вы консерватор (понимаю повторяюсь, но так и есть) и нужно надежное хранилище;
— вы или ваш специалист умеете настроить и использовать PostgreSQL;
— вам нужны хорошо структурированные данные, но с некоторой гибкости в схеме данных (JSON/BJSON);
— при помощи сторонних библиотек просто и удобно расширяться в кластеры и делать шардинг таблиц. И все это действительно работает.

А минусов как то вот не особо описывать… Справедливости ради, особо практики не имел, в основном сужу по рассказам знакомых:

— необходимость опыта работы с этой СУБД, чтобы приготовить ее хорошо. Иначе лучше взять MySQL или прочитать дальше;
— система авторизации по умолчанию может вызвать затруднения при использовании или настройке, далеко не всем нравится, некоторые даже очень опытные разработчики до сих пор не до конца понимают как оно там работает.

MongoDB

О, сколько копий до сих пор ломается — SQL или NoSQL… Но все же в некоторых случаях MongoDB справляются с задачей гораздо лучше, чем MySQL или PostgreSQL. Например, реальный случай, свидетелем которого я был — сбор и обработка статистики по хостингу (нагрузка на CPU, i/o, память и т.п.) — MySQL не справился от слова вообще. MongoDB справился без особых проблем. База данных достигает объема в 200-300 ГБайт, поток данных достигает 100 и более МБайт/сек. Показательно, на мой взгляд.

MongoDB для вас, если:

— у вас нет четкой, заранее описанной структуры данных или вы предполагаете, что состав данных может потом сильно изменится (конечно это можно делать в SQL, но надо мыслить другими понятиями, поменять то можно, но вопрос насколько это будет трудоемко);
— у вас планируется довольно серьезный объем данных (десятки или даже сотни ГБ), определить это даже на этапе ТЗ можно;
— вам просто хочется NoSQL, модно же;
— легко установить и попробовать, работает нормально без особых настроек. А если углубится, изучить, то настроить можно очень многое.

Минусы тоже есть.

— Нет простых транзакций. По крайней мере в том, классическом виде, какие они есть в MySQL/PostgreSQL. При добавлении множества данных, которые зависят друг от друга, могут быть определенные трудности, которые придется решать самостоятельно на уровне кода. Ну то есть вы можете и не столкнутся конечно, но…;
— связность данных практически отсутствует. Сразу приходит на ум, постоянно упоминают JOIN из SQL — вот этого по сути нет. Хотя, если быть более точным, то надо просто мыслить другими категориями;
— нужно перестраивать мышление именно под NoSQL. иначе будет сложно сопровождать — то есть хороший программист (точнее архитектор ПО) обязателен в дальнейшем.

Redis

Чаще всего эту СУБД используют в качестве кеширующего слоя для работы с данными из другой, более медленной СУБД. Лучшая замена memcached, если вам это что-то скажет. Редко, но все же может использоваться в качестве самостоятельно БД для данных. При этом Redis умеет разные типы данных, в том числе списки, очереди, умеет Pub/Sub, а еще очень просто работать с TTL (время жизни ключа). Работает в памяти, очень быстрая, умеет сохранять данные на диске, причем с поддержкой дозаписи (гораздо меньше нагружает диск) и загружать при запуске. Почти сказка.

Redis для вас, если:

— объем данных небольшой и очень простая схема, укладывающая в шаблон «ключ=значение»;
— простая реализация репликации Master — Slave. Действительно очень простая настройка, достаточно добавить в конфиг сервера указания на мастера, запустить Redis Server и данные уже реплицируются. Хотя, наверное, следует уточнить, что настроить гибкую репликацию (частичную) вряд ли получится;
— нужен Pub/Sub (очереди). Справедливости ради следует сказать, что есть отдельные системы Pub/Sub, реализующие помимо этого паттерна и другие. Redis реализует это достаточно элегантно и просто, вполне возможно вам другие не понадобятся;
— нужен кеш для более медленной СУБД или просто хотите не задумываться о скорости работы СУБД с оглядкой на ее объем. Примером может послужить сайт на Drupal, с основной базой данных в MySQL и кешем в Redis. Проводил тесты ради интереса обычным ab, скорость отдачи контента может увеличится в разы. На обычном Apache + Redis + mod_php можно достичь сравнимой производительности с Nginx + php-fpm, а если к Nginx добавить Redis…

Минусы тоже есть, как же без них.

— объем данных не должен превышать объем свободного ОЗУ на вашем сервере (на самом деле может, но тогда все они будут уходить в swap, сильно замедлять работу, в общем лучше избегать);
— в угоду производительности присутствует довольно слабая сохранность данных. То есть вполне может произойти такое, что данные добавили, а после рестарта их нет. Включение AOL (append of file) немного сглаживает ситуацию, но тогда загрузка с диска будет довольно длительной;
— транзакции и связанные данные не то, чтобы умеет. Если точнее — есть Pipeline и Multi/Exec, но это все таки не совсем транзакция в классическом понимании;
— до сих пор не умеет нормально кластер и шардинг. Нормальной реализации до сих пор нет.

Конечно можно напрячься и сделать что-то похожее на кластер при помощи специального скрипта, но на мой взгляд выглядит это довольно кривовато и неоптимально.

Альтернативы

Из личного опыта и блуждания по интернету, изучения разных статей, обзоров я встречал несколько различных вариантов, которые можно применить в случае, если вас что-то не устроило в предыдущих вариантах. Итак, встречайте еще несколько интересных проектов.

IBM Lotus Domino/Notes

На мой взгляд ярчайший пример успешного коммерческого проекта СУБД концепции NoSQL. Хотя подозреваю, что успех скорее не в его NoSQL, а в наличии полноценного сервера приложений с встроенным редактором кода и интерфейса к базе. Решение очень зрелое, существует на рынко довольно давно и поддерживается гигантом IBM — ну то есть очень даже круто. Лично участвовал в разработке двух разных систем электронного документооборота на его базе, а также сопровождал некоторые критично важные приложения в банке. Кстати, несмотря на платную политику распространения, мало кто знает, но его можно бесплатно скачать для изучения.

CouchDB

Хотите хранить документы разной структуры (ну как MongoDB, типа), но у вас нет для приложения адаптера или не хотите лишних зависимостей? CouchDB работает через http, имеет встроенный веб-сервер, обменивается в JSON. Очень удобно. Кстати умеет транзакции и можно подписываться на изменения данных. Но это не точно.

PouchDB

Это очень интересный проект, как бы аналог CouchDB, но более приземленный, встраиваемый вариант. Встроили в приложение, работает как локальная база данных, но умеет настраиваемую репликацию с CouchDB или PouchDB Server (на базе ExpressJS). PouchDB на самом деле скорее прослойка, где снаружи вы работаете с единым API, CouchDB-подобным, но внутри может быть совсем разные СУБД — и SQLite и LevelDB и браузерная база данных и MongoDB и даже MySQL. Очень пригодится, если вы делаете распределенное приложение, где обмен данными важен, но связь с сервером может быть нестабильной или эпизодической.

Aerospike

На мой взгляд отличная замена Redis в плане key/value БД. Умеет транзакции, умеет сохранность данных, умеет большой объем данных (превышающий объем доступной ОЗУ). Правда нет Pub/Sub и каких-то особых структур данных, но работает быстро и хорошо. Пожалуй единственным недостатком это слабая популярность по сравнению с Redis. Непонятно кстати почему…

Apache Cassandra

Спроектирована и работает как распределенная NoSQL СУБД для больших данных. Данные хранит в виде семейства столбцов, что сперва может изменить кардинально подход к разработке приложения. Но после ломки мышления вполне может оказаться, что это именно то, что вам надо. Заявлено простое добавление узлов на лету, высокая отказоустойчивость при выходе одного из узлов. В теории можно использовать на небольших проектах, но выглядеть будет наверное, как будто микроскопом забивать гвозди.

Tarantool

Замечательный проект от Mail.Ru. Что-то среднее между Redis/Aerospike и MongoDB… Хотя по моему сами разработчики до сих пор затрудняются провести аналогии :). Его надо уметь, а если быть более точным хотеть готовить. И речь не про настройку, а про постоянную подгонку под разработку новых версий Tarantool. Нужно хотеть вникать во внутреннее устройство этого проекта, постоянно изучать изменения его API и документации, все время подгонять код приложения под изменения. А если вы еще и хотите поучаствовать в процессе разработки, пообщаться с разработчиками в чате — тогда тем более это для вас.

А вот теперь как бы и все.

Да, я упомянул далеко не все СУБД (если смотреть на этом сайте, то там перечислено 253 названия). Надеюсь вы и не думали, что я их все перечислю?

Возможно в описании той или иной СУБД я допустил неточность и не упомянул нечто важное. Такое очень даже возможно и если так — напишите в комментариях, я с интересом почитаю.
Надеюсь мои выводы окажутся полезными и интересными.

UPD1: По поводу отказоустойчивости MySQL. Вы все правы. Я не заявляю, что InnoDB нестабильна, я лишь упомянул, что ситуация это возможна. И если она произойдет, то восстановить работоспособность никак нельзя будет, только начисто восстанавливать все целиком из бекапа. Именно об этом речь, а не о том, что вы решили будто я считаю ее нестабильной. По реальному примеру, на серверах у нас такое произошло за последний год 2 или 3 раза. На разных серверах. На сервере несколько сотен баз с разной нагрузкой, объемов и т.п. Это не значит, что у вас MySQL будет падать регулярно на виртуалке с одним-двумя сайтами, совсем не об этом речь. Как то так.

Какую СУБД выбрать и почему

Когда начинается разработка масштабного проекта, в котором будут использоваться базы данных, часто начинаются споры о том, какую СУБД выбрать. У каждой есть свои сторонники, поэтому споры могут быть жаркими. В этой статье мы расскажем, какие системы управления базами данных бывают и для каких ситуаций выбрать тот или иной тип.

Какие СУБД существуют и как их выбирать

Систем управления базами данных очень много. Но реально используют перечисленные ниже:

1. Реляционные
2. Key-value
3. Документные
4. Графовые
5. Колоночные
6. Time Series
7. Spatial
8. Search engines
9. Объектные

Детальнее о них расскажем позднее, но сейчас перечислим критерии выбора СУБД, которые должны стать реперными точками при выборе. Итак, какую СУБД можно выбрать для проекта:

• Тип проекта. Для небольшого pet-project может подойти любая встраиваемая или бесплатная СУБД. Коммерческий проект требует от СУБД соблюдения стандартов безопасности, производительности, скорости работы и т. д. Здесь возможностей бесплатных СУБД может не хватить.
• Что будет храниться. Некоторые СУБД лучше работают с текстом, другие заточены под медиаконтент. Если знать, что будет храниться в БД, выбор СУБД станет проще.
• Объём. В технической документации для каждой СУБД указаны лимиты на объём одного файла, таблицы и других объектов. В случае, когда нужно хранить большие массивы данных, заранее проверьте способность системы управления базами данных «переваривать» такие объёмы.
• Нагрузка и масштабируемость. Важно заранее предусмотреть возможный рост нагрузки, который неизбежно возникнет при расширении компании. Бесконечно наращивать оперативную память, процессоры и другие ресурсы не получится, поэтому выбирайте СУБД с прицелом на способность переносить текущие и двукратно увеличенные нагрузки, а также масштабироваться в будущем.
• Файловая или серверная. Ваша база данных может работать по сети и локально. От этого зависит выбор СУБД. Они бывают файловые и серверные.
• Отказоустойчивость и безопасность. Для некоторых проектов отказоустойчивость — критично важный параметр. Что будет, если упадёт БД банка, объяснять не нужно. Поэтому ориентируйтесь на реальные потребности проекта в уровне отказоустойчивости СУБД. Аналогично и с безопасностью — сертификаты, шифрование, дополнительные возможности нужны для крупных проектов. Небольшому достаточно и менее «навороченной» СУБД.
• Стоимость. Существуют бесплатные опенсорсные решения, которые дают много возможностей, но требуют самостоятельной поддержки. Есть платные СУБД с поддержкой от разработчика. Выбор зависит от бюджета проекта.

Далее рассмотрим типы СУБД и их особенности.

Реляционные СУБД

Классическое решение, появившееся в 1979 году благодаря компании Oracle. Реляционные БД построены на отношениях между её объектами и пригодны для обработки небольших транзакций с обилием вставок и минимальным временем отклика. Например, Oracle Database подойдёт для коммерческих проектов, где требуется производительность и есть ресурсы для администрирования этой дорогой и сложной СУБД.

Из бесплатных серверных СУБД выделяется MySQL, которая отлично тянет небольшие и средние проекты. А компактная и встраиваемая файловая SQLite хорошо вписывается в маленькие проекты, поскольку она проста в управлении и обладает достаточной функциональностью.

Также хорошо известны Microsoft SQL, PostgreSQL. Получается, что нельзя ответит на вопрос, какая СУБД лучше, MySQL или PostgreSQL. Они обе хорошо для своих задач.

Документные

Документно-ориентированные СУБД хранят документы — структурированные тексты, имеющие конкретный синтаксис. Это популярная разновидность NoSQL СУБД, которая подходит для проектов, где в таблицах хранят объекты с разной структурой (списки, словари). Нельзя сказать, что это база для систем документооборота, хотя Документные СУБД сохраняют состояние, а не поведение. Зато они поддерживают проверку схему и сейчас активно развиваются. Среди популярных СУБД этого типа — CouchDB, MongoDB, Amazon DocumentDB.

Графовые

Особые СУБД, предназначенные для хранения информации, связанной с графами (узлы, вершины, связи между узлами). Хорошо подходят для социальных сетей, где требуется хранить связи между пользователями по разным критериям. Среди популярных СУБД этого типа можно перечислить Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid.

Колоночные

Колоночные БД отличаются от реляционных тем, что информация в них хранится столбцами, а не построчно. Значение атрибута любого из объектов прочитывается сразу. Используются они в качестве хранилищ данных с большим (от ста миллионов записей) объёмом информации, и при обработке скромных объёмов не способны продемонстрировать свои преимущества.

Колоночные СУБД удобны тем, что позволяют действительно быстро выполнять сложные аналитические запросы на больших объёмах данных. При этом структура таблиц с данными легко меняются, а эффективная компрессия позволяет экономить занимаемый БД объём памяти. Среди популярных СУБД этого типа можно назвать Vertica, ClickHouse, Google BigTable, InfoBright, Cassandra, SAP IQ.

Key-value

СУБД Key-value (также её называют «ключ-значение») — одна из самых из самых простых систем управления базами данных. Фактически она представляет собой таблицу с уникальным ключом и привязанным к нему значением. СУБД Key-value очень быстрые, поэтому их часто используют для кэширования данных и для брокеров сообщений. Некоторые типы таких СУБД позволяют работать полностью в памяти и задавать срок жизни записи, удаляя устаревшие данные. Среди популярных Key-value СУБД — Redis и Memcached.

Time Series

СУБД данного типа заточены под хранение данных временных меток или рядов. Например, данные собранные с датчиков контроля движения, метрик JVM, сетевые данные, ответы API и т. д. Информация хранится с отметками времени. Причём эти отметки индексируются и пишутся так, чтобы сведения можно было запрашивать быстрее, чем при работе с реляционными БД. Среди популярных СУБД этого типа можно вспомнить InfluxDB, Kdb+, Prometheus, TimescaleDB, QuestDB, AWS Timestream, OpenTSDB, GridDB.

Spatial

СУБД данного типа сконфигурированы для хранения геометрически ориентированных объектов: простых (линии, точки, многоугольники) и сложных (линейные сети, 3D-объекты). В них можно проводить с объектами разные операции — создания, трансформации, измерения, вычисления и пр. Такого рода СУБД обладают собственным типизированным SQL/MM языком. Среди популярных СУБД этого типа можно вспомнить Oracle Spatial, Microsoft SQL, PostGIS, SpatialLite.

Search engines

Этот тип СУБД необходим для организации полнотекстового поиска по разным данным (email, RSS-feed, JSON, XML, CSV), позволяет искать данные из других БД, по документам PDF и Microsoft Office. Такие СУБД используют инвертированные индексы, чтобы искать практически в режиме реального времени. Среди популярных СУБД этого типа можно назвать Apache Solr, Elasticsearch, Splunk.

Объектные

Данный тип СУБД предназначен для хранения и работы с объектами, у которых имеются свойства и методы. Основная задача таких СУБД заключается в избавлении разработчиков, использующих ООП, от необходимости трансформировать объекты в таблицы/строки и обратно. В объектных СУБД реализованы инкапсуляция и полиморфизм. Среди популярных СУБД этого типа можно назвать MongoDB Realm, InterSystems Caché, ObjectStore, Actian NoSQL DB, Objectivity/DB.

• MS SQL Web;
• MS SQL Standard;
• PostgreSQL (typical);
• PostgreSQL (high availability);
• MySQL (typical);
• MySQL (high availability).

Когда выбирать

Популярные СУБД данного типа

Нужна транзакционность; высокая нормализация; большая доля операций на вставку

Oracle, MySQL, Microsoft SQL Server, PostgreSQL, IBM DB2, SQLite

Задачи кэширования и брокеры сообщений

Redis, Memcached, etcd

Для хранения объектов в одной сущности, но с разной структурой; хранение структур на основе JSON

Couchbase, MongoDB, Amazon DocumentDB

Задачи подобные социальным сетям; системы оценок и рекомендаций

Neo4j, Amazon Neptune, InfiniteGraph, TigerGraph

Хранилища данных; выборки со сложными аналитическими вычислениями; количество строк в таблице превышает сотни миллионов

Vertica, ClickHouse, Google BigQuery, Sybase \ SAP IQ, InfoBright

Системы мониторинга, сбора телеметрии, и финансовые системы, с привязкой к временным меткам или временным рядам

InfluxDB, Kdb+, Prometheus, TimescaleDB, QuestDB, AWS Timestream, OpenTSDB, GridDB

Высокопроизводительная обработка данных, имеющих сложную структуру, с использованием языков объектно ориентированного программирования

MongoDB Realm, InterSystems Caché, ObjectStore, Actian NoSQL DB, Objectivity/DB

7 типов современных баз данных: предназначение, достоинства и недостатки

Существуют сотни баз данных SQL и NoSQL. Одни популярны, другие игнорируются. Некоторые просты и хорошо документированы, а некоторые сложны в использовании. Одни имеют открытый код, а другие проприетарные. Что, возможно, наиболее важно, некоторые масштабируемы, оптимизированы, высокодоступны, а некоторые сложно масштабировать или поддерживать.

Возникает естественный вопрос: какую базу данных выбрать? Чтобы ответить на него, мы должны решить, чего мы хотим достичь с помощью базы данных. Чтобы составить представление, необходимо ответить на следующие вопросы:

1. Нужен ли нам аналитический доступ к базе данных?
2. Нужно ли нам писать или читать в реальном времени?
3. Сколько таблиц / записей мы хотим сохранить?
4. Какая доступность нам нужна?
5. Нужны ли нам столбцы?
6. Сможем ли мы получить доступ к таблицам, отфильтрованным по столбцам или по строкам?

Принимая решение, нужно помнить, что может предложить та или иная база данных. Специфика каждой БД может отличаться, но в целом существует только несколько типов, в рамках которых мы можем достичь в основном одинаковых целей. Рассмотрим их подробнее.

Реляционные базы данных SQL

Если вы когда-либо работали с базами данных, скорее всего, вы начали с этого типа, потому что он самый популярный и распространенный. Такие БД позволяют хранить данные в реляционных таблицах с определенными столбцами определенного типа. Реляционные таблицы хороши для нормализации и объединения.

Достоинства:

• Поддержка SQL
• ACID-транзакции (атомарность, согласованность, изоляция и долговечность)
• Поддержка индексации и разделения

Недостатки:

• Плохая поддержка неструктурированных данных / сложных типов
• Плохая оптимизация обработки событий
• Сложное / дорогое масштабирование

Примеры: Oracle DB, MySQL, PostgreSQL.

Документно-ориентированные базы данных

Если мы не хотим объединять несколько таблиц для получения нужных данных, мы можем взглянуть на документно-ориентированные базы данных. Они позволяют хранить записи в формате JSON. В этом формате мы можем создать сложное значение для любого ключа и сразу включить всю структуру данных в одну запись.

Достоинства:

• Нет привязки к схеме
• Нет необходимости всегда писать все поля в каждой записи
• Хорошая поддержка сложных типов
• Подходит для OLTP

Недостатки:

• Плохая поддержка транзакций
• Слабая аналитическая поддержка
• Сложное / дорогое масштабирование

Примеры: MongoDB.

Базы данных в оперативной памяти

Базы данных этого типа могут предоставлять в реальном времени ответ для выбора и вставки определенных записей. Большинство из них в основном хранят данные в ОЗУ, но в некоторых случаях они также предлагают постоянное хранилище на жестких дисках или твердотельных накопителях. Большинство этих баз данных работают с записями «ключ-значение», поэтому значения можно запоминать в формате, ориентированном на документы. Но некоторые базы данных также работают со столбцами и позволяют вторичное индексирование той же таблицы. Использование ОЗУ позволяет обрабатывать данные быстро, но делает их более нестабильными и дорогостоящими.

Достоинства:

• Быстрое написание
• Быстрое чтение

Недостатки:

• Труднодостижимая надёжность
• Дорогое масштабирование

Примеры: Redis, Tarantool, Apache Ignite.

Базы данных с широкими столбцами

Эти базы данных хранят данные в виде записей ключ / значение на жестком диске или твердотельном накопителе. Эти решения предназначены для достаточно хорошего масштабирования, чтобы управлять петабайтами данных на тысячах общих серверов в распределенной системе. Они представляют архитектуру SSTable. Эта архитектура была разработана для двух случаев использования: быстрый доступ к ключу и быстрая запись с высокой доступностью.

Достоинства:

• Быстрая запись построчно
• Быстрое чтение по ключу
• Хорошая масштабируемость
• Высокая доступность

Недостатки:

• Формат «ключ-значение»
• Нет поддержки аналитики

Примеры: Cassandra, HBase.

Столбчатые базы данных

Иногда нам нужно быстро получить доступ к данным не с помощью определенных ключей, а с помощью определенных столбцов. В этом случае лучше отказаться от построчной вставки и перейти к пакетной записи. Пакетная вставка позволяет столбчатым базам данных готовить данные для быстрого чтения по столбцам.

Достоинства:

• Быстрое чтение столбец за столбцом
• Хорошая аналитическая поддержка
• Хорошая масштабируемость

Недостатки:

• Подходит только для пакетных вставок

Примеры: Vertica, Clickhouse.

Поисковая система

Если мы хотим получить доступ к данным с помощью фильтра по любому значению и даже по любому слову в столбце, мы должны вспомнить про поисковые системы. Эти базы данных выполняют индексацию каждого слова в столбцах и позволяют выполнять полнотекстовый поиск. Они идеально подходят для хранения и анализа журналов или больших текстовых значений.

Достоинства:

• Быстрый доступ по любому слову
• Хорошая масштабируемость

Недостатки:

• Подходит только для пакетных вставок
• Плохая аналитическая поддержка

Примеры: Elastic.

Графовые базы данных

Для некоторых случаев подходят графовые структуры данных. Если ваши задачи требуют работы с графами, существуют специальные базы данных, которые удовлетворят ваши потребности.

Достоинства:

• Структура данных графа
• Управляемые отношения между сущностями
• Гибкие конструкции

Недостатки:

• Специальный язык запросов
• Трудно масштабировать

Выводы

Практически любую задачу можно выполнить практически с любым типом базы данных. Вопрос в том, насколько это будет дорого и оптимизировано. Выбор инструмента, к которому вы привыкли, может сократить ваше время вывода на рынок. Но он также может стоить вам огромных денег на обслуживание и расширение вашего оборудования, которое может быть использовано неэффективно. Всегда старайтесь использовать базу данных так, как она задумана. Возможно, решение, соответствующее вашим потребностям, уже существует.

Если вы готовитесь к собеседованию, посмотрите также статью, в которой собраны 27 распространённых вопросов по SQL и ответы на них.