Современные приложения не вписываются в четкие рамки категорий баз данных, как и системы, работу которых они обеспечивают, пишет на портале The New Stack Джесси Холл, специалист по работе с разработчиками компании MongoDB.

Традиционная таксономия баз данных осталась в прошлом. Такие термины, как «NoSQL», «реляционная», «документная», «ключ-значение» и «графовая», которые мы использовали более десятилетия, больше не описывают, как работают современные базы данных и что на самом деле нужно разработчикам.

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

Ловушка категоризации

Категории баз данных возникли из-за реальных технических ограничений. В начале 2000-х существовали очевидные компромиссы:

  • Реляционные базы данных обеспечивали ACID-транзакции и структурированные запросы, но испытывали трудности с масштабированием и развитием схем.
  • Хранилища документов предлагали гибкие схемы и горизонтальное масштабирование, но в них отсутствовали транзакции и сложные запросы.
  • Хранилища «ключ-значение» обеспечивали высокую производительность, но минимальные возможности для запросов.
  • Графовые базы данных превосходно справлялись с взаимосвязями, но плохо работали с другими схемами доступа.

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

Результатом стало «мультивариантное хранение» («polyglot persistence») — использование разных баз данных для разных частей одного приложения. Типичный современный стек может включать PostgreSQL для транзакционных данных, Redis для кэширования, Elasticsearch для поиска, Neo4j для рекомендаций и InfluxDB для метрик.

Этот подход работал, пока системы были небольшими, и у команд было время управлять сложностью. В современной среде разработки он не работает.

Конвергенция

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

Эта конвергенция происходит благодаря исчезновению первоначальных технических ограничений. Методы распределенных вычислений, казавшиеся экзотикой в 2010 г., стали стандартом. Компромиссы, связанные с теоремой Брюера (CAP — Consistency, Availability, Partition Tolerance; утверждение о том, что в любой реализации распределенных вычислений возможно обеспечить не более двух из трех следующих свойств: согласованность, доступность, устойчивость к фрагментации), казавшиеся фундаментальными, оказались приемлемыми благодаря улучшению алгоритмов и инфраструктуры.

Взгляните на то, что произошло в ландшафте баз данных.

В PostgreSQL появились столбцы JSONB, что сделало ее пригодной для работы с документами. Теперь она включает полнотекстовый поиск, расширения временных рядов и даже поиск по сходству векторов для приложений ИИ.

Redis вышла за рамки простых операций «ключ-значение» и получила модули для поиска, обработки графов, JSON-документов и данных временных рядов.

Apache Cassandra внедрила вторичные индексы, материализованные представления и более гибкое моделирование данных.

Даже традиционные реляционные базы данных, такие как SQL Server и Oracle, добавили поддержку JSON, возможности работы с графами и гибкость в стиле NoSQL.

MongoDB также продвинулась в этой конвергенции. То, что начиналось как документная база данных, теперь обеспечивает ACID-транзакции в распределенных кластерах, полнотекстовый и векторный поиск на базе Apache Lucene и другие современные функции.

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

Почему это важно для разработчиков

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

Эта консолидация устраняет целые классы проблем:

  • Отсутствие синхронизации данных. Когда профили ваших пользователей, кэш сеансов, поисковые индексы и аналитика находятся в одной системе, вам не нужны сложные конвейеры ETL (извлечение, преобразование, загрузка) для обеспечения согласованности данных.
  • Единый язык запросов. Разработчики изучают один синтаксис вместо SQL, команд Redis, Cypher и любого доменно-ориентированного языка, используемого вашей поисковой системой.
  • Единая операционная модель. Одна стратегия резервного копирования, одна система мониторинга, один подход к масштабированию, одна модель безопасности.
  • Согласованность транзакций. Операции, охватывающие несколько типов данных, могут использовать одни и те же гарантии ACID, устраняя сложность распределенных транзакций, которая преследовала мультивариантные архитектуры.

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

Переоценка мультивариантного подхода

Мультивариантное хранение имело смысл, когда базы данных имели жесткие ограничения. Оно теряет смысл, когда эти ограничения исчезают.

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

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

Рассмотрим поиск. Elasticsearch стал выбором по умолчанию для полнотекстового поиска, поскольку реляционные базы данных плохо справлялись с ним. Но если Atlas Search обеспечивает время отклика менее миллисекунды, используя ту же платформу Apache Lucene, что и Elasticsearch, то в чем смысл поддержки отдельного поискового кластера?

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