От чего зависит выбор СУБД, какие факторы надо учитывать, чтобы обосновать возможность использования знакомой технологии для хранения и обработки данных или необходимость перехода на новое решение.
Требования к СУБД или критерии выбора решения
База данных (БД) – сердце почти любой информационной системы: ведь именно в ней хранятся данные, необходимые для решения бизнес-задач. За целостность выполнения операций над этими данными отвечает система управления базой данных (СУБД). Чтобы сделать обоснованный выбор, какая СУБД больше подойдет для проекта, следует определить требования к этой системе. Требования к решению принято делить на функциональные и нефункциональные. Однако, такое определение как факторов выбора СУБД мне показалось не очень подходящим, поскольку в случае СУБД ее многие функции почти неотделимы от условий их выполнения. В частности, основными функциями СУБД является хранение и обработка данных. Но выбор зависит от того, какие требования по отклику и условиям выполнения предъявляются к этим функциям, а также какова природа самих данных, их объемы и скорость поступления в систему.
Поэтому в данной статье, которая совершенно не претендует на полноценное руководство по выбору СУБД, а аккумулирует мой опыт и знания, я решила представить в виде 20 факторов и разделить критерии выбора на 2 категории:
- основное назначение СУБД – какие данные она должна хранить и обрабатывать, каковы сценарии применения этих функций с ожидаемыми данными и частота их выполнения;
- возможности и ограничения – какие дополнительные функции есть в СУБД, каковы ее внутренние характеристики и факторы внешнего окружения, которые влияют на конечный выбор.
Назначение СУБД
Начнем с назначения СУБД, которое сводится к определению того, какие данные нужно хранить и обрабатывать. Прежде всего, следует понять структуру самих данных: насколько она вариативная. Для хранения данных со строгой заранее определенной структурой отлично подходит табличная модель организации, которую поддерживают реляционные и колоночные СУБД. Но, например, чтобы сделать выбор между классической реляционной и колоночной СУБД, следует рассмотреть варианты использования этих данных и их объемы. В частности, реляционные СУБД (MySQL, PostgreSQL, MariaDB и пр.) отлично подходят для транзакционных систем, обеспечивая атомарность, консистентность, изоляцию и долговечность транзакций. А колоночные хранилища (ClickHouse, DuckDB и т.д.) оптимизированы под быстрое выполнение агрегаций и сложных аналитических запросов с огромными объемами данных с приблизительными результатами. Другие категории NoSQL-решений тоже отлично справляются с большими объемами и ориентированы на специфические задачи, такие как обход графов, поиск по документам (JSON, YAML, XML и пр.), операции с векторами, анализ временных рядов и т.д.
Таким образом, первичная модель организации данных в структуры хранения (таблицы, графы, документы) определяет основное назначение СУБД, с которым она справляется лучше всего. Например, векторные СУБД (Pinecone, SingleStore, Qdrant, Vespa и пр.) хранят данные в виде векторов, что актуально для ИИ-систем. А графовые (Neo4j, TigerGraph, AllegroGraph, NebulaGraph и т.д.) представляют данные как граф знаний — набор вершин, связанных направленными или ненаправленными ребрами. Благодаря быстрому обходу графа задачи поиска расстояний и выявления сообществ решаются намного быстрее, чем в классических реляционных СУБД, где данные представлены в виде таблиц с жесткой структурой столбцов, связанных по внешним ключам. Примеры таких сравнений я показывала здесь.
Однако, большинство современных СУБД поддерживают не одну, а несколько моделей организации данных. К примеру, моя любимая PostgreSQL, будучи классической реляционной СУБД, может вести себя как графовая, если установить расширение AEG, или как векторная с расширением pgvector. Благодаря поддержке типов данных JSON и JSONB, PostgreSQL позволяет работать с JSON-документами, включая поиск ключей, значений и проверки вхождения. Аналогичные возможности есть в PostgreSQL и для XML-документов. Поэтому PostgreSQL подходит для хранения и обработки данных различных структур в большинстве транзакционных систем с не очень большим объемом данных, т.е. помещающихся на один сервер. Такое ограничение объема связано с тем, что из коробки PostgreSQL не поддерживает шардирование. Впрочем, это тоже обходится с помощью расширения citus, которое позволяет горизонтально масштабировать PostgreSQL.
Возвращаясь к моделям организации данных в структуры хранения, которые обусловливают категорию СУБД (реляционная, графовая, векторная, колоночная, ключ-значение, документо-ориентированная и пр.), отмечу, что не только PostgreSQL, но и многие другие СУБД поддерживают не только первичную, но и другие модели. Например, ArangoDB, которая может вести себя как документно-ориентированная, графовая и ключ-значение, Cosmos DB – распределенная мультимодельная документно-ориентированная и графовая БД с поддержкой табличного API, SAP HANA – реляционная резидентная СУБД, позволяющая работать с JSON-документами и графами. Подобных примеров можно привести очень много.
Впрочем, несмотря на поддержку нескольких моделей данных, в мультимодельных СУБД именно первичная организации данных в структуры хранения является базисом, относительно которого надстроены остальные модели. Но эффективность их работы всегда ниже, чем у основной. К примеру, как уже было отмечено, PostgreSQL с расширением AEG может работать как графовая, но на больших и сложных графах будет делать это хуже специализированной графовой СУБД.
Поэтому для принятия решения о выборе важно определить не только структуру данных, их объемы и типовые сценарии запросов, но и частоту выполнения этих сценариев. Например, если 90% сценариев – это типовые транзакционные операции с не очень большими объемами данных строгой структуры, с этим отлично справится PostgreSQL. А справиться с оставшимися 10% аналитических операций с графами или документами ей помогут встроенные или специально установленные расширения. Но если 90% сценариев связаны с операциями полнотекстового поиска по множеству документов с вариативной структурой, целесообразно смотреть в сторону документо-ориентированных решений (Elasticsearch, Opensearch, MongoDB и пр.).
Еще важна персистентность хранения данных: нужно ли обеспечивать долговременное и надежное сохранение их на диск или предполагается применять БД для временного хранения оперативных данных, например, промежуточные вычисления и внутренние переменные приложения. Для этого обычно применяются легковесные in-Memory решения, о которых я писала здесь.
Наконец, следует учитывать характер поступления данных в БД и максимально допустимую задержка обработки. Например, если данные поступают бесконечным потоком в режиме реально времени из брокеров сообщений, датчиков конечных устройств и других интерактивных источников, и их надо обрабатывать сразу, по мере поступления, с этими сценариями отлично справляются потоковые СУБД (RisingWave, Materialize и др.). Благодаря коннекторам и материализованным представлениям с автоматическим обновлением они позволяют выполнять агрегатные операции над потоком данных. Причем в качестве инструмента запросов обычно используется классический SQL. Кстати, язык обращения к данным тоже может стать из факторов выбора решения, наряду со следующими критериями, которые я отнесла к группе возможностей и ограничений, рассмотренных ниже.
Возможности и ограничения СУБД как факторы принятия решений о выборе
Таким образом, помимо основного назначения СУБД, которое сводится к определению структуры данных (таблицы, графы, документы) и характеру работы с ними (OLTP- или OLAP-сценарии, т.е. ориентация на запись или на чтение), для выбора еще важны дополнительные функции, внутренние характеристики и факторы внешнего окружения:
- объем данных для хранения. Как уже было отмечено, не все СУБД являются распределенными и поддерживающими горизонтальное масштабирование через шардирование. Большинство NoSQL-решений (Apache HBase, ClickHouse, MongoDB, Elasticsearch и др.) являются распределенными и их механизмы запросов изначально спроектированы так, чтобы оперировать с данными, распределенными по нескольким узлам.
- возможности настройки и расширения. Сюда можно отнести как возможность создания собственных типов данных, добавление новых функций с помощью расширений или других инструментов, так и смену/настройку движка СУБД, который отвечает за физическое хранение данных, обработку запросов и выполнение операций чтения и записи. Например, в колоночной СУБД Clickhouse около 20 табличных движков, каждый со своей областью применения. Возможность настройки движка может пригодиться для определения размера страницы (блока) БД для оптимального чтения и записи. В частности, маленькие страницы (2-8 КБ) подходят для OLTP-сценариев с большим количеством транзакций и небольшими записями, где важна быстрая обработка, а большие (от 16 КБ) – для OLAP c большими объемами данных. Не все СУБД позволяют менять или настраивать свои внутренние механизмы. Также к возможностям конфигурирования можно отнести поддержку подсказок (хинтов, hint) в запросах, которые указывают оптимизатору, как строить план выполнения запросов, отличающийся от предопределенных правил. Разумеется, такая тонкая настройка предполагает отличное понимание внутренних механизмов работы СУБД и на практике требуется нечасто.
- инструменты оптимизации и разработки, такие индексы, триггеры, внутренний язык для разработки хранимых функций и процедур, поддержка разделения (партиционирования) крупных структур данных на несколько более мелких. В отличие от шардирования, партиционирование предполагает разделение набора данных в пределах одного сервера, чтобы ускорить операции за счет меньшего объема сканирования.
- средства взаимодействия с СУБД: интерфейсы, протоколы, коннекторы, поддерживаемые языки программирования и библиотеки для них. Удобно, когда помимо нативных протоколов, СУБД поддерживает текстовый HTTP-протокол и универсальные JDBC- и ODBC-драйверы, что упрощает смену БД без больших изменений на уровне кода приложения.
- пропускная способность СУБД — сколько данных можно обрабатывать за единицу времени. Это свойство сильно зависит от потребляемых ресурсов и максимального количества соединений, т.е. числа одновременных сеансов связи между клиентом (приложением) и сервером СУБД, которое может быть на текущем программно-аппаратном окружении. Обычно количество соединений ограничено, но его можно расширить через изменение в конфигурационных настройках или с помощью пулеров соединений, например, PgBouncer, PgPool-II, ProxySQL, HikariCP и пр., которые работают на уровне СУБД или на уровне приложения, группируя и проксируя набор соединений.
- механизмы и инструменты репликации. Удобно, если СУБД поддерживает не только физическую репликацию на основе на копирования файлов и логов, но и логическую для CDC, т.е. отслеживания изменений данных. Например, в PostgreSQL поддерживаются оба варианта репликации. Кроме того, для некоторых случаев нужна синхронная, а для других – асинхронная репликация. А топология кластера БД (мастер-реплика или кольцо) определяет направления копирования изменений: с главного узла на узлы реплик или последовательное распространение изменений с любого узла на другие. Не все СУБД поддерживают любые возможные варианты репликации. Частично это ограничение снимается с помощью внешних инструментов резервного копирования данных, таких как Qlik Data Replication, Vinchin Backup&Recovery и др.
- требования к программно-аппаратному окружению. На какой операционной системе и с какими аппаратными ресурсами (ЦП, ОЗУ, диски, сеть) СУБД будет работать наиболее эффективно. Например, колоночные и векторные СУБД изначально ориентированы на работу с большими объемами данных, организованных по столбцам. Поэтому они имеют векторизированные механизмы запросов, которые стараются по максимуму использовать преимущества многопоточной обработки на всех ядрах ЦП, когда при выполнении одной инструкции процессора производится не одна операция, а одновременно несколько однотипных операций над несколькими порциями данных. Аналогичную специфику имеет операционная система ОС, на которой устанавливается и работает СУБД. Обычно это Unix/Linux-подобные решения, но могут быть и серверные ОС от Windows, на которой отлично работает MS SQL Server. Таким образом, программно-аппаратное окружение, в котором планируется развертывание СУБД, может стать фактором принятия решения.
- схема лицензирования и стоимость покупки. Многие СУБД имеют бесплатную community-версию и/или открытый исходный код, что позволяет без существенных затрат и ограничений использовать их в коммерческих и некоммерческих проектах. Другие являются проприетарными решениями с платными тарифами и специальными условиями оплаты, включая условия к резидентству пользователей. Например, в последние несколько лет многие СУБД, разработанные в западных странах даже с бесплатной community-версией и открытым исходным кодом стали трудно доступными для пользователей из России. В частности, Atlas — облачная версия MongoDB. В прошлом году я лично столкнулась с невозможностью использовать бесплатную версию serverless-службы графовой СУБД Neo4j, которая раньше успешно работала. Более того, из РФ стал недоступен даже просмотр документации с официального сайта Neo4j. Поэтому лицензия, открытость или закрытость исходного кода, стоимость покупки, а также юрисдикция вендора могут стать влиятельными факторами выбора СУБД.
- Впрочем, сумма арендных платежей или разового приобретения – не последний фактор, связанный с деньгами. Важна также стоимость поддержки и сопровождения, которая напрямую связана с распространенностью технологии на рынке. У более зрелых технологий, которые существуют более 5 лет, обычно есть подробная документация и развитое сообщество, специалистов, умеющих работать с этим решением. Это значит, что найти разработчика, аналитика или администратора на популярную СУБД будет намного проще и дешевле, чем на экзотичную технологию, которая появилась совсем недавно.
- Еще один важным фактором выбора является опыт команды разработки и сопровождения с СУБД, и порог входа в технологию. Конечно, профессиональные инженеры довольно быстро способны освоить новый стек при наличии документации и примеров. Однако, сложные и специфичные концепции, свойственные отдельно взятым СУБД могут увеличить длительность периода адаптации. Разумеется, если при прочих равных условиях выбирать между знакомым и не знакомым решением, предпочтителен первый вариант.
- Наконец, выбор СУБД должен соответствовать техрадару компании – внутреннему архитектурному документу, который определяет стек технологий, допустимых к промышленному использованию или подходящими для исследований. В крупных и технологически зрелых компаниях вероятность выбора СУБД, не входящей в категории ADOPT или TRIAL корпоративного техрадара, довольно мала.
Рассмотренный перечень критериев выбора СУБД может дополняться и другими факторами, которые влияют на принятие решений. Про это и другие темы, связанные с проектированием и эксплуатацией баз данных я рассказываю на курсах Школы прикладного бизнес-анализа и проектирования информационных систем в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
