СУБДиариум современного инфраструктурщика
Еще относительно недавно (каких-то лет 10–15 назад) выбор СУБД для приложения в среднестатистической корпоративной среде ограничивался всего тремя вариантами: Microsoft SQL, Oracle и MySQL. При этом каждое решение имело свою нишу. Нужно что-то серьезное под большую нагрузку — вот вам Oracle, что-то попроще — MS SQL, а если какое-то веб-приложение — то MySQL.
Но все чаще в корпоративной инфраструктуре появляются задачи, требующие нового подхода к выбору СУБД. Речь про потребности, которые смогут закрыть СУБД на основе искусственного интеллекта, или такие решения, как Big Data и NoSQL. При подборе новых решений традиционный способ выбора только ограничивает поиск и не дает нужной производительности и гибкости. При этом часто выбор СУБД сводится к «поставим PostgreSQL, на нем точно заработает». Да, в большинстве случаев заработает, так как сама по себе PostgreSQL модульная и из нее, как из конструктора, можно много чего сделать, но какими усилиями и ресурсами? Быть может, уже на этапе выбора платформы стоит задуматься о том, что подойдет лучше?
В этой статье я расскажу, какие сейчас бывают СУБД и как их можно систематизировать под конкретную задачу. Сразу оговорюсь: я не претендую на истину в последней инстанции, и вполне возможно, что кто-то смотрит на структурирование СУБД по-своему.
Обратимся к истории
Становление привычных реляционных баз пришлось на 80-е годы прошлого века, где в битве двух идеологий (QUEL vs SQL) выяснялось, чье кунг-фу сильнее. С одной стороны, это Майкл Стоунбрейкер, профессор Калифорнийского университета в Беркли со своими компетентными теоретиками, с другой — основатель Oracle Ларри Эллисон, привлекавший для развития своего продукта лучших программистов Кремниевой долины и профессуру Стэндфордского университета. В этой битве, как мы знаем, победил более практический коммерческий подход, и стандарт SQL на долгие годы укрепился в умах. Речь, конечно же, про глобальный мир. Разрабатываемые в то время советские модели хранения и управления данными ни с кем не бились, а в большинстве своем даже не вышли из лабораторий на коммерческий рынок.
Развитие нереляционных СУБД (NoSQL) происходило и продолжает происходить хаотично, иногда без какой-либо теоретической подготовки. Часто программистам не нужна мощная СУБД со всем ее функционалом, а необходим только какой-то маленький кусочек или что-то специфическое, чего нет ни в одной СУБД — и, чтобы решить свою задачу, они пишут что-то свое. Результатом такого подхода стало огромное количество СУБД под любые типы задач, нагрузки, реализации. Какие-то из них используются буквально в нескольких проектах, а другие стали популярными решениями в своем направлении. Разобраться во всем этом многообразии не так-то просто.
Структурирование СУБД
Чтобы понять, почему так сложно выбрать новую СУБД под проект, достаточно задаться вопросом, а сколько же всего СУБД существует? Судя по различным «базам баз» в интернете, их количество стремительно приближается к тысяче и постоянно увеличивается. Даже пока вы читаете эту статью, скорее всего, в мире родилась новая СУБД.
При таком количестве продуктов не может же быть так, что все они одинаковые? Действительно, в первом приближении выделяются классические реляционные базы, в которых основа всей структуры — обязательная связность, и нереляционные, где подходы к учету хранения данных не подразумевают их связи между собой. Такие разные подходы в основном обусловлены различными данными, хранение которых не всегда можно структурировать. Отсюда вытекает, что самое простое, как можно категорировать СУБД, — это по типу хранения или модели данных, где на сегодняшний момент можно выделить следующие разновидности:
классические реляционные;
ключ-значение;
документоориентированные;
семейства колонок;
временные ряды;
графовые;
объектные;
векторные.
Последний тип стал сейчас особенно выделяться на фоне роста популярности различных языковых моделей нейронных сетей. У каждого типа хранения есть свои особенности, например, при документоориентированном способе важна не индексация записей, а наличие свойств документов, позволяющих их объединять или группировать в запросах. И как показывает практика, хранение документов в базе такого типа, например MongoDB, значительно ускоряет работу с ними относительно хранения тех же самых документов в любой реляционной базе данных.
Казалось бы, на этом можно было остановиться. Но входные условия по выбору СУБД не всегда ограничиваются только типами хранения. В крупных корпоративных инфраструктурах часто используется подход горизонтального масштабирования, при котором данные распределяются по нескольким серверам. Например, механизм шардирования позволяет разбивать большие таблицы на более мелкие части (шарды) и хранить их на разных узлах кластера. Это значительно увеличивает производительность и объем обрабатываемых данных, что для больших аналитических систем является ключевым условием. Такой пример демонстрирует необходимость решения задач высокой нагрузки и больших объемов данных. Масштабирование является важным дополнением к различным типам хранения данных и позволяет классифицировать СУБД как монолитные или распределенные.
Рисунок 2. Логическая схема монолитной и распределенной СУБД
Ниже варианты СУБД с разным типом хранения данных и с разбивкой на монолитные и распределенные:
Рисунок 3. Распределение СУБД по модели данных и масштабированию
При распределении существующих СУБД по предложенным метрикам уже получается стройная двухмерная картинка, где все разложено по полочкам и остается только выбрать по входным условиям, какие параметры требуются именно вам. Но все ли учтено?
Еще одним популярным требованием в корпоративных СУБД стало хранение данных в памяти. Скорость ответов на запросы в БД при таком размещении данных самая быстрая на текущий момент, что для ряда задач является крайне важным фактором. Получается, что есть еще одна важная метрика, добавляющая выбор в третьем измерении. Обрисовывать трехмерную плоскость для графического представления нового разреза еще можно, но уже становится довольно сложной задачей. Но там явно есть популярные решения, например, GreenPlum — реляционная и распределенная СУБД с возможностью хранения данных на дисках. Или другой пример известной распределенной базы с хранением в памяти — Tarantool. Она сочетает в себе несколько типов, а именно реляционный, ключ-значение и документоориентированный.
Кроме этого, очевидно, что нагрузки на базы бывают разные. В одном случае требуется построить отчет из холодных данных и можно подождать, пока он сформируется (OLAP-нагрузка). Чаще всего такая нагрузка встречается в аналитических БД вроде корпоративного хранилища данных. В другом случае нужно быстро записать в базу критичные данные, иначе «все пропало» (OLTP-нагрузка), и самый простой пример таких нагрузок — процессинг банка, где незаписанная транзакция в базе приведет к потере денег. Чтобы понять, насколько большая разница между этими типами нагрузки, достаточно обратиться к цифрам:
Рисунок 4. OLTP- и OLAP-нагрузка
Что в итоге
Получается, что тип нагрузки становится четвертым измерением для категорирования СУБД, а раскладывать табличку в четырехмерном пространстве — уже задача сложная. Поэтому предлагаю свести выбор к опроснику. Исходя из описанных выше категорий, для выбора подходящего решения достаточно ответить на четыре вопроса.
Какие типы данных будут храниться?
Необходимо ли распределенное хранение данных?
Требуется ли обработка запросов к данным памяти?
Какая нагрузка предполагается? OLAP или OLTP?
Ответы на эти вопросы дадут относительно небольшую выборку решений, которые лучше подойдут в конкретной ситуации. К ней можно было бы добавить еще какие-то нюансы, с которыми сталкиваются в корпоративных инфраструктурах реже, но которые могут в некоторых случаях повлиять на выбор. Например, методы интеграции СУБД с внешними системами. Но автор посчитал приведенные выше характеристики более существенными. При этом писать, что лучше, а что хуже для разного типа задач, осознанно не стал. При таком богатстве выбора всегда найдется решение, подходящее именно вашей инфраструктуре, команде разработки и сопровождения.
Автор: Евгений Ярош, начальник отдела реализации проектов «Инфосистемы Джет»
