Почти все представленные на рынке СУБД условно можно разделить на восемь основных типов: реляционные; графовые; документные; поколоночные (столбцовые); типа «ключ — значение»; временных рядов; объектно-ориентированные; поисковые. При решении конкретных прикладных задач представители каждого из этих типов имеют как свои плюсы, так и минусы.

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

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

Графовые. Основное предназначение таких СУБД — работа с графами, их узлами и свойствами, а также отношениями между узлами. Например, они хорошо подходят для поддержки социальных сетей, посетители которых связаны общими интересами, работой или родством. Самые известные в России графовые СУБД — Comindware ElasticData и Neo4j. Ограниченно доступные или недоступные: Amazon Neptune, InfiniteGraph, InfoGrid.

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

Документные, или документоориентированные, — популярная разновидность нереляционных СУБД. В качестве базовой единицы логической модели данных в ней используется структурированный текст со специфическим синтаксисом (документ). Считается, что модели данных документных и объектно-ориентированных баз данных аналогичны, но различия все же есть: документные хранят не поведение объектов, а только их состояние. Самые известные документные СУБД: Tarantool [4], CouchDB, MongoDB, а также недоступная в России Amazon DocumentDB.

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

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

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

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

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

СУБД временных рядов. Такие СУБД оптимизированы для хранения данных с метками времени или данных временных рядов. Данные содержат измерения или события, которые отслеживаются, собираются или объединяются за определенный период времени: сведения с датчиков отслеживания движения, метрики JVM из приложений на Java, данные о рыночной торговле, сетевые данные, ответы от API, время безотказной работы процесса и т. д. Данные хранятся с метками времени — это ключевая особенность — индексируются и записываются они так, сведения временного ряда запрашивались намного быстрее, чем при использовании в классической РСУБД. Самые известные СУБД такого типа: InfluxDB, Prometheus, TimescaleDB, QuestDB и ClickHouse. Ограниченно доступные или недоступные в России: Kdb+, AWS Timestream, OpenTSDB.

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

Объектно-ориентированные. Эти СУБД предназначены для хранения и обработки объектов, имеющих свойства и методы, а также поддерживающих свойства инкапсуляции и полиморфизма. Главная цель применения этих систем — облегчить жизнь разработчикам, использующим модель объектного программирования, которым не нужно преобразовывать объекты в таблицы и строки со связями и обратно. Известные объектно-ориентированные СУБД — MongoDB Realm, InterSystems Cache [5], ObjectStore, Actian NoSQL DB, Objectivity/DB.

Объектно-ориентированные базы данных рекомендуется использовать для организации высокопроизводительных манипуляций с объектами, имеющими сложную структуру, особенно в случаях, когда разработка предполагает применение объектно-ориентированных языков программирования. Такие СУБД распространены в системах реального времени, архитектуре и инженерии для 3D-моделирования, телекоммуникациях и пр. Обычно нет смысла выбирать объектно-ориентированную СУБД, когда используется классический язык SQL или когда не применяется ООП.

Поисковые. Этот тип СУБД используется для поддержки полнотекстового поиска, а также поиска по различным данным, например, из других баз данных, электронной почты, RSS-канала, плоского текста, JSON, XML, CSV, документов в форматах PDF и Microsoft Office. В таких СУБД имеются собственные оптимизированные подходы к индексированию данных, используются инвертированные и фасетные индексы для поддержки поиска почти в реальном времени. Самые известные поисковые СУБД — Apache Solr, Elasticsearch, Splunk.

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

Какая СУБД нужна?

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

  • Назначение базы данных: OLAP, OLTP или оба? Задачи, возникающие при оперативной аналитической обработке данных (Online Analytical Processing, OLAP), обычно требуют выгрузки больших массивов данных, например, сведений за продолжительные периоды. Задачи OLTP подразумевают обработку большого количества транзакций (большое количество записей в систему). В случае OLTP подойдут реляционные СУБД с высокой нормализацией. Для OLAP в свою очередь подойдут реляционные СУБД с низкой нормализацией, поколоночные и распределенные СУБД.
  • Какой объем данных планируется хранить? Объем весьма существеннен для реляционных баз данных, поскольку они позволяют осуществлять только вертикальное масштабирование и не подразумевают возможности добавления новых узлов, что требует резервировать дисковые мощности.
  • Сколько пользователей будет обращаться к базе при пиковой нагрузке? Количество и поток обращений пользователей к базе существенно влияют на выбор СУБД, поскольку при его изменениях и возрастании до существенных величин РСУБД оказываются медленнее из-за невозможности горизонтального масштабирования системы и создания распределенной структуры.
  • Какой требуется уровень доступности и масштабируемости? Возможности быстрого и безболезненного масштабирования — это ахиллесова пята всех реляционных СУБД, подразумевающих вертикальное масштабирование, которое весьма дорого. Как следствие, если ожидается взрывной рост объемов данных в рамках проекта, то имеет смысл обратить внимание на нереляционные базы данных.
  • Как часто меняются схемы базы данных? В реляционных базах данных каждое изменение схемы требует затрат ресурсов администраторов, поэтому в таком случае лучше отказаться от РСУБД.
  • Какие системы уже функционируют в компании и с какими придется интегрировать базу? Зачастую при внедрении СУБД в организации уже имеются информационные системы, генерирующие и потребляющие данные в различных форматах. Ряд из них (системы бизнес-аналитики, каталоги) имеют свои коннекторы и свои особенности в работе с различными СУБД, что следует учитывать.
  • Бюджет и специалисты? Необходимо четкое понимание наличия и уровня квалификации собственных кадров — в первую очередь дата-инженеров — и их компетенции в сфере развертывания и поддержки инфраструктуры базы данных. Сочетание этих двух факторов позволит сделать выбор в сторону коммерческого или свободного программного обеспечения, а также определиться с необходимостью привлечения сторонних специалистов для развертывания и поддержки базы.
Современные СУБД — выбор есть
Рис. 1. Алгоритм выбора СУБД

Некоторым подспорьем в выборе может быть диаграмма (рис. 1), помогающая определить пул подходящих СУБД.

Дополнительные рекомендации

Ориентиром для определения реалистичных требований к СУБД может быть CAP-теорема (теорема Брюера [6]) — при выборе системы из трех факторов: согласованность (consistency), доступность (availability), устойчивость к распределению (partition tolerance) достижимы только два, поэтому выбирать надо наиболее важные для конкретной задачи (рис. 2).

Рис. 2. Различные СУБД в контексте CAP-теоремы

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

Множество аспектов различных СУБД и САР-теорема ведут к простому следствию — не существует идеальной базы данных на все случаи жизни.

Выбор конкретных СУБД

По назначению:

  • OLAP: колоночные, распределенные и массивно-распределенные СУБД (ArenaDataDB [7], Greenplum, ClickHouse, Apache Druid и т. д.);
  • OLTP: реляционные СУБД с высокой нормализацией, распределенные и In-Memory СУБД (Квант-гибрид, PostgreSQL, Tarantool, PostgresPro [1] и т. д.).

По масштабируемости:

  • вертикальная масштабируемость: реляционные СУБД («Квант-Гибрид», PostgreSQL, PostgresPro и т. д.);
  • горизонтальная масштабируемость: распределенные СУБД (ArenaDataDB, Greenplum, ClickHouse, Tarantool и т. д.).
  • По модели лицензирования:
  • коммерческие российские (PostgresPro, Cronos PRO и т. д.);
  • коммерческие зарубежные (AWS, Oracle, IBM DB2 и т. д.);
  • свободное ПО (ClickHouse, ArenaDataDB, Apache Druid, MongoDB, PostgreSQL и т. д.).
Рис. 3. СУБД для OLAP и OLTP

На рис. 3 приведена подготовленная на основе исследования «СУБД-круг Громова 2023» схема выбора СУБД по их типу.

Рис. 4. Диаграмма выбора СУБД

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

***

Выбор СУБД для проекта всегда зависит от задач и ограничений конкретной задачи. Несмотря на исход западных вендоров в России достаточно решений, как коммерческих, так и с открытым исходным кодом, для решения насущных задач отечественных компаний. А снижение конкурентного давления открывает окно возможностей для разработчиков.

Литература

1. Марк Ривкин. СУБД для высоконагруженных систем // Открытые системы.СУБД. — 2023. — № 2. — С. 17–23. URL: https://www.osp.ru/os/2023/02/13057166 (дата обращения: 21.09.2023).

2. Константин Селезнев. Реляционная СУБД для современного оборудования // Открытые системы.СУБД. — 2023. — № 2. — С. 24–27. URL: https://www.osp.ru/os/2023/02/13057249 (дата обращения: 21.09.2023).

3. Сергей Муравьев, Сергей Дворянкин, Игорь Насенков. СУБД: проблема выбора // Открытые системы.СУБД. — 2015. — № 1. — С. 22–24. URL: https://www.osp.ru/os/2015/01/13045322 (дата обращения: 21.09.2023).

4. Денис Аникин, Сергей Пугачев. Tarantool: СУБД с хранением в памяти и сервер приложений // Открытые системы. СУБД. — 2017. — № 2. — С. 32–34. URL: https://www.osp.ru/os/2017/02/13052224 (дата обращения: 21.09.2023).

5. Олег Оленин. NoSQL: назад в будущее // Открытые системы.СУБД. — 2012. — № 2. — С. 30–32. URL: https://www.osp.ru/ os/2012/02/13012856 (дата обращения: 21.09.2023).

6. Сергей Кузнецов. Пусть расцветают сто цветов // Открытые системы.СУБД. — 2013. — № 2. — С. 48–51. URL: https://www.osp.ru/os/2013/02/13034557 (дата обращения: 21.09.2023).

Станислав Алексеев (stanislav.a@businessqlik.com) — бизнес-аналитик, компания BI Consult (Санкт-Петербург).