Как выбрать СУБД для нового проекта

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

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

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

Для стандартных проектов и задач целесообразно применять специализированные инструменты, включая системы управления базами данных – это существенно увеличит скорость разработки и поможет избежать проблем.

Например, используя Redis для организации КЭШа, мы получаем из коробки невероятную скорость на чтение и запись, способность хранить различные структуры данных, встроенный механизм настройки срока хранения данных плюс огромное количество готовых рецептов конфигурирования и решения типовых проблем, доступных в сети. Сложно отрицать, что эти факторы значительно упростят разработку и поддержку этого решения.

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

СУБД можно разделить на несколько ключевых категорий:

Реляционные СУБД являются наиболее популярным видом систем управления базами данных. Их основа – реляционная алгебра, которая по своей сути базируется на теории множеств, а данные организуются в виде двумерных таблиц, представленных строками и столбцами. Система строго контролирует типы данных, ограничения, на них наложенные, связи и отношения между таблицами, что обеспечивает целостность данных и предотвращает ошибки. Реляционная модель, благодаря своей математической основе, позволяет объединять таблицы и создавать из них сложные структуры. Для работы с такими базами данных используется язык SQL (Structured Query Language), который предоставляет возможности для выполнения операций по выборке, добавлению, изменению и удалению данных.

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

Хранилище ключей и значений (КЗ-хранилище) является самой простой из всех рассматриваемых моделей. Как следует из названия, КЗ-хранилище сопоставляет значения ключам, подобно словарю или хэш-таблице в любом языке программирования. Некоторые КЗ-хранилища допускают в качестве значений составные типы данных, такие как хэши или списки, но это необязательно. В некоторых реализациях ключи можно перебирать, что также считается дополнительным преимуществом. Примером КЗ-хранилища можно считать файловую систему, где путь к файлу рассматривается как ключ, а его содержимое — как значение. Поскольку от КЗ-хранилища требуется так мало, базы данных этого типа могут демонстрировать невероятно высокую производительность, однако они могут быть бесполезны в случаях, когда требуются сложные запросы и агрегирование данных.

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

Колоночные базы данных сохраняют данные по столбцам вместо традиционного подхода с хранением по строкам. Это дает значительные преимущества при работе с большими объемами информации, особенно в аналитических задачах, где требуется быстро извлекать данные из отдельных столбцов. Такие СУБД идеально подходят для систем OLAP (Online Analytical Processing), обеспечивая высокую производительность при выполнении аналитических запросов.

Сводная таблица:

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

Что же делать, если проект не стандартный? Как же понять, какая из СУБД та самая, которая нужна именно в этом проекте?

Для этого надо понять, что СУБД должна делать (функциональные требования) и как работать (нефункциональные требования).

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

Доступные модели данных: реляционная, документная, графовая, ключ-значение и другие. Поддержка обработки неструктурированных данных (например, JSON).

Работа с данными: сюда относятся используемый язык запросов (SQL или др.), наличие дополнительных возможностей (агрегатные функции, подзапросы, представления, индексирование и т.д.).

Поддержка транзакции: ACID, поддержка работы с распределенными транзакциями.

Масштабируемость: поддержка как горизонтального, так и вертикального масштабирования, а также возможности шардирования и репликации.

Сложность интеграции: совместимость с другими системами и технологиями, наличие API и библиотек для различных языков программирования.

Под словами “как работать”, мы понимаем характеристики, которые определяют производительность, безопасность, надежность, удобство использования и прочее. Разберем их чуть подробнее:

Производительность: высокая скорость отклика на запросы, обработка больших объемов данных и поддержка одновременной работы с большим числом подключений.

Безопасность: интеграция механизмов аутентификации и авторизации, шифрование данных и управление доступом.

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

Удобство администрирования: легкость установки и настройки, наличие инструментов для мониторинга и управления системой.

Поддержка и сообщество: доступ к документации, обучающим материалам, активное сообщество и оперативная техническая поддержка.

Стоимость: затраты на лицензии (если применимо), инфраструктуру и обслуживание.

Гибкость: возможность адаптации под изменяющиеся бизнес-требования, поддержка различных типов данных и сценариев использования.

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

Процесс начинается с создания концептуальной модели данных, которая описывает ключевые сущности, их атрибуты и взаимосвязи. Для визуализации часто используется ER-диаграмма (Entity-Relationship). Этот этап помогает сформировать общее представление о структуре и функциональности базы данных до ее физической реализации.

Технические характеристики:

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

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

Затем следует определить приоритеты: скорость обработки данных или объем хранимой информации. Это помогает выбрать между двумя типами обработки запросов:

• OLTP (Online Transaction Processing): подходит для сценариев, требующих обработки большого количества транзакций в режиме реального времени, таких как финансовые системы, интернет-магазины или мессенджеры. Эти системы обеспечивают высокую производительность и быструю реакцию.
• OLAP (Online Analytical Processing): предназначен для аналитической обработки данных. Такие системы подходят для задач бизнес-аналитики, где важна работа с историческими данными и агрегирование информации.

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

Идентификация СУБД по CAP-теореме:

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

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

Масштабируемость: Распределенные системы позволяют увеличивать вычислительные мощности и ресурсы по мере необходимости, добавляя новые узлы в систему.

Отказоустойчивость: Если один узел выходит из строя, другие узлы могут продолжать выполнять задачи, что повышает надежность системы в целом.

Производительность: Распределение нагрузки между несколькими узлами может значительно увеличить общую производительность системы, особенно при выполнении ресурсоемких задач.

Географическая распределенность: Распределенные системы могут обслуживать пользователей из разных регионов, что снижает задержки и улучшает пользовательский опыт.

Теорема CAP (см. Рисунок 1) раскрывает неприглядную правду о том, что при всех плюсах распределенных систем, в условиях нестабильной сети создать распределенную систему, которая будет согласованной, доступной и устойчивой к потере связанности – невозможно. Система может обладать только двумя из трех перечисленных характеристик.

Если система не устойчива к потере связанности, то она не будет распределенной. Соответственно приходиться выбирать между гарантиями доступности или согласованности. Часто можно пойти на компромисс и применить подход Eventual consistency (согласовано в конечном), когда есть вероятность получить не актуальные данные, но в конечном итоге система будет согласована.

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

Вот и все технические аспекты, которые необходимо учесть при выборе СУБД.

Есть еще и нетехническая составляющая, которая также может оказать ощутимое влияние на выбор. Стоит учесть такие аспекты как:

Комьюнити: популярность решения обеспечивает доступ к большому количеству готовых решений и обсуждений, что упрощает поиск ответов на типичные и нестандартные вопросы.

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

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

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

Осталось собрать все в кучу и составить пошаговый алгоритм выбора СУБД.

Алгоритм принятия решения:

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

Наша команда уже более пяти лет занимается реализацией проектов на Java и усилением команд по направлениям

• DevOps;
• Java разработка;
• Тестирование.

За время существования компании, мы принимали участие в работе над более чем 100 проектами различного объема и длительности.

Если перед вами стоят вызовы, для достижения которых вам может понадобится наша экспертиза, просто напишите нам,

• client@softwarecats.dev,
• https://t.me/alex_zarubin,
• или через любую форму на сайте.

Мы договоримся с вами об онлайн-встрече, чтобы подробнее обсудить ваш проект и вашу проблему.