Еще относительно недавно (каких-то лет 10–15 назад) выбор СУБД для приложения в среднестатистической корпоративной среде ограничивался всего тремя вариантами: Microsoft SQL, Oracle и MySQL. При этом каждое решение имело свою нишу. Нужно что-то серьезное под большую нагрузку — вот вам Oracle, что-то попроще — MS SQL, а если какое-то веб-приложение — то MySQL.

Но все чаще в корпоративной инфраструктуре появляются задачи, требующие нового подхода к выбору СУБД. Речь про потребности, которые смогут закрыть СУБД на основе искусственного интеллекта, или такие решения, как Big Data и NoSQL. При подборе новых решений традиционный способ выбора только ограничивает поиск и не дает нужной производительности и гибкости. При этом часто выбор СУБД сводится к «поставим PostgreSQL, на нем точно заработает». Да, в большинстве случаев заработает, так как сама по себе PostgreSQL модульная и из нее, как из конструктора, можно много чего сделать, но какими усилиями и ресурсами? Быть может, уже на этапе выбора платформы стоит задуматься о том, что подойдет лучше?

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

Обратимся к истории

Становление привычных реляционных баз пришлось на 80-е годы прошлого века, где в битве двух идеологий (QUEL vs SQL) выяснялось, чье кунг-фу сильнее. С одной стороны, это Майкл Стоунбрейкер, профессор Калифорнийского университета в Беркли со своими компетентными теоретиками, с другой — основатель Oracle Ларри Эллисон, привлекавший для развития своего продукта лучших программистов Кремниевой долины и профессуру Стэндфордского университета. В этой битве, как мы знаем, победил более практический коммерческий подход, и стандарт SQL на долгие годы укрепился в умах. Речь, конечно же, про глобальный мир. Разрабатываемые в то время советские модели хранения и управления данными ни с кем не бились, а в большинстве своем даже не вышли из лабораторий на коммерческий рынок.

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

Структурирование СУБД

Чтобы понять, почему так сложно выбрать новую СУБД под проект, достаточно задаться вопросом, а сколько же всего СУБД существует? Судя по различным «базам баз» в интернете, их количество стремительно приближается к тысяче и постоянно увеличивается. Даже пока вы читаете эту статью, скорее всего, в мире родилась новая СУБД.

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

• классические реляционные;

• ключ-значение;

• документоориентированные;

• семейства колонок;

• временные ряды;

• графовые;

• объектные;

• векторные.

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

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

Ниже варианты СУБД с разным типом хранения данных и с разбивкой на монолитные и распределенные:

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

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

Кроме этого, очевидно, что нагрузки на базы бывают разные. В одном случае требуется построить отчет из холодных данных и можно подождать, пока он сформируется (OLAP-нагрузка). Чаще всего такая нагрузка встречается в аналитических БД вроде корпоративного хранилища данных. В другом случае нужно быстро записать в базу критичные данные, иначе «все пропало» (OLTP-нагрузка), и самый простой пример таких нагрузок — процессинг банка, где незаписанная транзакция в базе приведет к потере денег. Чтобы понять, насколько большая разница между этими типами нагрузки, достаточно обратиться к цифрам:

Что в итоге

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

1. Какие типы данных будут храниться?

2. Необходимо ли распределенное хранение данных?

3. Требуется ли обработка запросов к данным памяти?

4. Какая нагрузка предполагается? OLAP или OLTP?

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

Автор: Евгений Ярош, начальник отдела реализации проектов «Инфосистемы Джет»