Наука о данных

Как выбрать СУБД для решения ваших задач?

02.12.2021

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

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

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

Вот список наиболее часто используемых СУБД:

Реляционная СУБД.
Графовая СУБД.
Документная СУБД.
Столбцовая СУБД.
СУБД типа «Ключ — значение».
СУБД временных рядов.
СУПБД (система управления пространственными базами данных).
Поисковая СУБД.
Объектно-ориентированная СУБД.

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

Отметим, что у ряда крупных поставщиков имеется по нескольку типов СУБД — в виде отдельных продуктов или внутренних реализаций.

У Oracle, например, есть все: классическая реляционная БД; отдельный продукт Oracle NoSQL Database (нереляционная БД Oracle), применяющийся в качестве столбцовой, документной и базы данных типа «ключ — значение»; автономная база данных, ориентированная на хранилища данных; сервер для графов Oracle Graph Server и многие другие продукты.

Типы СУБД. Как выбрать правильный?

Реляционная СУБД

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

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

Самые известные реляционные СУБД:

Oracle;
Microsoft SQL;
PostgreSQL;
MySQL;
IBM DB2.

Когда следует выбирать реляционную базу данных?

Во-первых (1), при высокой нормализации данных. А во-вторых (2), при обработке большого количества коротких транзакций, среди которых немалый процент транзакций с вставкой.

Когда не следует выбирать реляционную СУБД?

Для хранения 1) неструктурированных данных и 2) очень простых структур «ключ — значение». Для первых лучше подойдет документная СУБД. А для вторых — специализированная СУБД типа «ключ — значение».

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

Графовая СУБД

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

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

Самые известные графовые СУБД:

Neo4j;
Amazon Neptune;
InfiniteGraph;
InfoGrid.

Когда следует выбирать графовую базу данных?

1) При создании соцсети или реализации рейтинговой и рекомендательной системы и 2) при глубоком понимании графов и их назначения.

Когда не следует выбирать графовую базу данных?

Почти во всех остальных случаях.

Документная СУБД

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

Считается, что модели данных документных и объектно-ориентированных БД аналогичны. Это так, хотя разница все же есть: документные БД не хранят поведение объектов, а только их состояние. Документные СУБД активно развиваются — некоторые даже поддерживают проверку схемы.

Самые известные документные СУБД:

CouchDB;
MongoDB;
Amazon DocumentDB.

Когда следует выбирать документную БД?

У документной СУБД широкий диапазон применения: от 1) компактной БД для одного микросервиса до 2) крупномасштабных решений в качестве хранилища состояния.

Лучше хранить объекты в одной сущности, но с разными структурами. Кстати, очень полезны они и 3) для хранения структур (включая объекты, списки и словари), особенно в JSON-подобном формате.

Когда не следует выбирать документную СУБД?

Документная система не подходит для реализации модели транзакций и, конечно, это не лучшее решение для формирования отчетов.

Столбцовая СУБД

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

Реляционная СУБД хранит данные построчно. То есть для считывания значения конкретного столбца приходится считывать почти всю строку — от первого до этого столбца.

Столбцовая СУБД хранит данные по столбцам. То есть столбец предстает в виде отдельной таблицы. А считывание выполняется прямо из конкретного столбца. На самом деле работает очень быстро — протестировано на нескольких реализованных хранилищах данных.

Преимущества столбцовой СУБД:

эффективно выполняет сложные аналитические запросы для большого объема данных;
простое и почти мгновенное реструктурирование таблиц с данными;
существенное сжатие, которое экономит много места.

Самые известные столбцовые СУБД:

Sybase IQ (SAP IQ);
Vertica;
ClickHouse;
Google BigQuery;
InfoBright;
Apache Druid.

Когда следует выбирать столбцовую БД?

1) При создании хранилища данных и осуществлении выборки со сложными аналитическими вычислениями. 2) Когда количество запрашиваемых строк превышает сотни миллионов.

Когда не следует выбирать столбцовую СУБД?

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

2) Когда запросы достаточно простые и со статичными параметрами. В этом случае — учитывая специфику системы — столбцовая СУБД будет неэффективна.

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

СУБД типа «ключ — значение»

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

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

Самые известные СУБД типа «ключ — значение»:

Redis;
Memcached.

Когда следует выбирать БД типа «ключ — значение»?

Она идеальна, когда 1) необходимо кеширование данных или брокеры сообщений и когда 2) надо хранить довольно простые структуры с быстрым доступом к ним.

Когда не следует выбирать БД типа «ключ — значение»?

Когда 1) в БД хранится много сущностей (таблиц), имеющих сложные структуры с разными типами данных. Когда 2) надо выполнять сложные запросы, возвращающие много строк.

СУБД временных рядов

Эта СУБД оптимизирована для хранения данных с метками времени или данных временных рядов. Данные временных рядов содержат измерения или события, которые отслеживаются, собираются или объединяются за определенный период времени.

Это данные с датчиков отслеживания движения, метрики JVM из приложений на Java, данные о рыночной торговле, сетевые данные, ответы от API, время безотказной работы процесса и т. д.

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

Самые известные СУБД временных рядов:

Когда следует выбирать СУБД временных рядов?

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

Когда не следует выбирать СУБД временных рядов?

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

Объектно-ориентированная СУБД

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

Главная цель применения объектно-ориентированной СУБД — облегчить жизнь разработчикам, использующим модель объектного программирования. Им не придется преобразовывать объекты в таблицы и строки со связями и обратно.

Самые известные объектно-ориентированные СУБД:

Когда следует выбирать объектно-ориентированную СУБД?

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

В то же время разработка 2) предполагает применение объектно-ориентированных языков программирования. Объектно-ориентированные БД распространены в системах реального времени, архитектуре и инженерии для 3D-моделирования, телекоммуникациях и научных продуктах, молекулярной науке и астрономии.

Когда не следует выбирать объектно-ориентированную СУБД?

1) При использовании классического языка SQL, 2) когда не применяется ООП или 3) при переходе на другую БД. И 4) при отсутствии глубокого понимания ООП. Тогда стоит выбрать документную СУБД.

Поисковая СУБД

Этот тип СУБД используется для осуществления полнотекстового поиска. А также поиска по различным данным, например из других БД, электронной почты, RSS-канала, текста, JSON, XML, CSV и даже PDF и документам MS Office.

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

Различные СУБД этого типа применяют разные языки запросов.

Самые известные поисковые СУБД:

Когда следует выбирать поисковую СУБД?

Идеальные примеры — подходящие для быстрого полнотекстового поиска в различных источниках данных системы сбора и поиска по журналам структурированных, полуструктурированных и неструктурированных данных.

Когда не следует выбирать поисковую СУБД?

При поиске по ограниченному числу полей структурированных данных.

СУПБД (система управления пространственными базами данных)

Этот тип СУБД оптимизирован для работы с объектами, определенными в геометрическом пространстве — как простыми (точки, кривые, многоугольники), так и сложными (3D-объекты, топологическое покрытие, линейные сети).

СУПБД имеет набор специальных функций для обработки создания, преобразования, измерения (расстояние, площадь, объем), вычисления (пересечение/контакт) и выбора на основе определенных критериев. И содержит специальные индексы, оптимизирующие обработку объектов, и особый стандартизированный язык SQL/MM.

Самые известные СУПБД:

Когда следует выбирать СУПБД?

При создании ГИС-решений — не только для хранения, но и для работы с геометрическими объектами на уровне СУПБД.

Когда не следует выбирать СУПБД?

Для хранения геометрических объектов в качестве координат.

Заключение

Определиться с выбором СУБД бывает нелегко, ведь их так много! Надеемся, вы немного прояснили для себя этот вопрос и теперь легко выберите подходящую.

Хотите создать сложное решение? Тогда понадобится несколько типов СУБД. И не торопитесь с выбором поставщиков СУБД: обычно это тема второстепенная.

Выбирайте тип СУБД на основе следующих трех факторов:

тип решаемых задач;
типы обрабатываемых данных;
перспективы роста и масштабирование.

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

В таблице в сжатом виде собрано все, что описывалось в статье:

Надеемся, статья была полезной.