Выбор СУБД: шпаргалка, чтобы не запутаться
Вопрос выбора СУБД для российской компании или госоргана — вопрос не праздный, тем более сейчас — когда с момента ухода с рынка западных вендоров прошло уже полтора года и пора что-то решать. Но как не запутаться в номенклатуре СУБД и выбрать ту, которая лучше всего подходит? Без ложной скромности скажу: мы в «Кругах Громова» уже немного поднаторели в систематизации, поэтому надеемся, что наша шпаргалка для тех, кто хочет выбрать СУБД, окажется полезной.
Начнем с классики. СУБД делятся на несколько типов. Не будем описывать их подробно, остановимся только на их основном предназначении.
Реляционные СУБД — чаще всего используется для 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) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.
(источник: https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_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
