Вопрос выбора СУБД для российской компании или госоргана — вопрос не праздный, тем более сейчас — когда с момента ухода с рынка западных вендоров прошло уже полтора года и пора что‑то решать. Но как не запутаться в номенклатуре СУБД и выбрать ту, которая лучше всего подходит? Без ложной скромности скажу: мы в «Кругах Громова» уже немного поднаторели в систематизации, поэтому надеемся, что наша шпаргалка для тех, кто хочет выбрать СУБД, окажется полезной.
Начнем с классики. СУБД делятся на несколько типов. Не будем описывать их подробно, остановимся только на их основном предназначении.
Реляционные СУБД — чаще всего используется для 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) достижимыми являются только два.
В нашем случае согласованность — это точность, полнота и корректность данных, находящихся в БД. Доступность — мера того, как часто информация из вашей БД доступна и насколько быстро можно получить/внести информацию в базу данных. Устойчивость к распределению — возможность двух сегментов системы работать даже в случае временного сбоя коммуникации в их сети (а также возможность работы при нарушении сетевой связности).
И вот как это выглядит в применении к имеющимся на рынке СУБД:
![Теорема САР Теорема САР](https://habrastorage.org/getpro/habr/upload_files/938/5f6/e3a/9385f6e3a45ddffb293ac7b3db7cfab0.jpg)
УБД также различаются по ряду технических параметров. Поговорим о них.
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. Сертификация
а) соответствие международным стандартам безопасности;
б) сертификация соответствия: наличие сертификатов, подтверждающих соответствие определенным нормам и требованиям;
в) защита данных: уровень защиты данных, включая шифрование, механизмы аутентификации и авторизации.
Конечно, классификация СУБД в разрезе указанных параметров может зависеть от конкретной реализации и конфигурации. Мы предлагаем лишь общие ориентиры для каждой СУБД из предложенного списка.
И вот как все эти факторы выглядят сведёнными на диаграмме Вена:
![](https://habrastorage.org/getpro/habr/upload_files/e8f/856/a2f/e8f856a2f7f3ebcf30f76d986ae92318.png)
Как определить, какая СУБД нужна?
Итак, чтобы определить, какую СУБД выбрать, следует задать себе следующие вопросы — и ответить на них:
Какого назначение вашей базы данных: OLAP, OLTP или оба?
Какой объем данных вы планируете хранить?
Как много пользователей будет обращаться к БД при пиковой нагрузке?
Какой уровень доступности, масштабируемости данных вам нужен?
Как часто будут меняться схемы БД?
И конечно больше деталей в «СУБД‑круге Громова» и в нашей шпаргалке DB Cheat Sheet: