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

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

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-подобном формате.

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

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

Telegram-канал по теме

NOP::HumorИТ-юмор и мемы о боли разработчиков

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

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

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

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

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

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

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

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.

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

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

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

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

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

Заключение

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

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

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

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

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

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

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