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

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

Реляционные СУБД — чаще всего используется для OLTP‑решений (обработка транзакций онлайн). Подходят для систем, предназначенных для хранения большого записей с различными типами отношений между ними. Самые известные — Oracle Database, Microsoft SQL Server, PostgreSQL, MySQL, IBM DB2, из российских — Postgres Pro, ЛИНТЕР и Ред База Данных. Плохо подходят они для неструктурированных данных, простых структур и случаев с частым обновлением строк.

Столбцовые (колонковые) СУБД — похожи на реляционные, но хранят данные по столбцам. Столбец предстает в виде отдельной таблицы, а считывание выполняется прямо из конкретного столбца. Т.о. они эффективно выполняют сложные аналитические запросы для большого объема данных, быстро реструктурируют таблицы с данными. Самые‑ Sybase IQ (SAP IQ), Vertica, ClickHouse, Google BigQuery, InfoBright, Apache Druid.

Применяют при сложной аналитике и объемах запрашиваемых строк более нескольких сотен миллионов.

Графовые СУБД — подходят для решения специфических задач.Самые известные графовые СУБД — Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid.

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

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

СУБД временных рядов. Сфера их применения — мониторинг, обработка телеметрии и финансовые системы. Но не стоит их использовать в задачах, не связанных с временными рядами и метками времени. Самые известные — InfluxDB, Kdb+, Prometheus, TimescaleDB, QuestDB, AWS Timestream, OpenTSDB, GridDB.

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

Поисковые СУБД — используются для осуществления поиска. Самые известные — Apache Solr, Elasticsearch, Splunk. Неэффективны при поиске по ограниченному числу полей структурированных данных.

Теорема САР

Одним из способов, позволяющих на верхнем уровне определить, какие реалистичные требования можно устанавливать к СУБД, может стать теорема САР (известная также как теорема Брюера). Она гласит, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств:

• согласованность данных (англ. consistency) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу;

• доступность (англ. availability) — любой запрос к распределённой системе завершается корректным откликом, однако без гарантии, что ответы всех узлов системы совпадают;

• устойчивость к разделению (англ. partition tolerance) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.

(источник: Теорема CAP).

То есть при выборе системы из трех факторов: согласованность (consistency), доступность (availability) и устойчивость к распределению (partition tolerance) достижимыми являются только два.

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

И вот как это выглядит в применении к имеющимся на рынке СУБД:

УБД также различаются по ряду технических параметров. Поговорим о них.

1. Структура данных

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

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

в) Реляционная структура: основана на концепции таблиц, где данные организованы в виде отношений. Реляционные базы данных используют SQL (Structured Query Language) для организации, хранения и извлечения данных. Таблицы связаны между собой ключами, что позволяет выполнять сложные запросы и анализировать данные.

г) Большой объем неструктурированных данных: БД содержит большое количество данных, которые не имеют четкой структуры или формата: текстовые документы, изображения, аудио‑ и видеофайлы. Обработка таких данных может быть сложной, требовать специальных методов и инструментов, например, алгоритмов машинного обучения или анализа естественного языка.

2. Схема лицензирования

а) Проприетарная лицензия: СУБД является собственностью компании‑разработчика, и доступ к ее исходному коду ограничен или отсутствует. Примеры проприетарных СУБД: Oracle Database, Microsoft SQL Server и IBM DB2.

б) Открытая лицензия (Open Source): код СУБД доступен общественности, его можно менять и распространять. Примеры: MySQL, PostgreSQL и SQLite.

в) Бесплатная лицензия (Freeware): можно пользоваться без ограничений, но с ограниченной или отсутствующей поддержкой и обновлениями. Бесплатные лицензии могут быть как проприетарными, так и открытыми.

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

3. Характер обращений

а) OLTP (Online Transaction Processing): большое количество несвязанных или слабо связанных между собой запросов, изменяющих значения в разных строках. Обработка каждого отдельного запроса должна происходить быстро, обычно в течение долей секунды.

б) OLAP (Online Analytical Processing): одновременный запрос гигантского количество однородных данных, которые потом агрегируются (чаще всего суммируются). Суммарное время обработки таких запросов должно составлять не более нескольких секунд.

в) Журналирование: огромное количество запросов на добавление новых записей при отсутствии изменения существующих.

4. Масштаб данных

а) малый объем – до 1 Гб, до 10 000 строк;

б) средний объем – 1 Гб – 1 Тб, 10 000 – 1 000 000 строк;

в) большой объем – от 1 Тб, более 1 000 000 строк.

Объем данных в БД может сильно варьироваться в зависимости от типа данных.

5. Параметры отказоустойчивости

а) надежность;

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

в) восстановление после сбоев: возможность быстрого восстановления после сбоев и сбойных ситуаций.

6. Сертификация

а) соответствие международным стандартам безопасности;

б) сертификация соответствия: наличие сертификатов, подтверждающих соответствие определенным нормам и требованиям;

в) защита данных: уровень защиты данных, включая шифрование, механизмы аутентификации и авторизации.

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

И вот как все эти факторы выглядят сведёнными на диаграмме Вена:

Как определить, какая СУБД нужна?

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

• Какого назначение вашей базы данных: OLAP, OLTP или оба?

• Какой объем данных вы планируете хранить?

• Как много пользователей будет обращаться к БД при пиковой нагрузке?

• Какой уровень доступности, масштабируемости данных вам нужен?

• Как часто будут меняться схемы БД?

И конечно больше деталей в «СУБД‑круге Громова» и в нашей шпаргалке DB Cheat Sheet: