В конце 2000-х главным вопросом проектирования был «SQL или NoSQL». Прошло полтора десятилетия, и оказалось, что победителя нет — но не потому, что все договорились. А потому, что сам вопрос перестал иметь смысл. Исследование Datadog, построенное на анализе более 2,5 миллиона сервисов в продакшене, показывает, как микросервисная архитектура переопределила то, как компании используют базы данных — и какие проблемы из этого выросли.
Что показало исследование
Сначала — сами цифры, на которые ссылается Datadog в статье «How microservice architectures have shaped the usage of database technologies»:
- Более половины организаций используют три и больше технологий баз данных одновременно.
- Четверть клиентов — пять и больше баз, что почти равно доле тех, кто до сих пор живёт на одной.
- Почти половина компаний параллельно держит и SQL, и NoSQL.
- Из девяти аналитических платформ 44% организаций используют хотя бы одну.
- Почти 70% клиентов внедрили очереди сообщений (лидеры — RabbitMQ, Kafka, AWS SQS).
Выглядит как история успеха: «правильный инструмент под каждую задачу». На практике за этими процентами прячется довольно дорогая организационная плата.
Почему так вышло
В монолите выбор базы был стратегическим — одно решение на всю организацию, одна общая база как точка интеграции. Переход на микросервисы сделал этот выбор тактическим: каждая команда вправе взять то, что лучше подходит её сервису. Хорошо для скорости разработки, но у этого есть обратная сторона.
Дробление схемы. Одна глобальная схема рассыпается на сотни и тысячи микро-схем. База перестаёт быть общим артефактом, который видят и разработчики, и аналитики, — и превращается в приватную деталь реализации конкретного сервиса.
Джойны становятся проблемой. Раньше join жил в базе и решался транзакцией. Теперь данные размазаны по разным хранилищам с разными схемами, и собрать их вместе нужно уже на уровне приложения.
Аналитика усложняется. Данные разбросаны, и чтобы построить отчёт, их надо свести в единую схему и слить в data warehouse.
И вот тут появляется GraphQL
Исследование показывает, как команды закрывают дыру от разрозненных данных: слой интеграции данных на базе GraphQL. Он тянет данные из нескольких хранилищ и API и сводит их под единой схемой. Логика join, которая когда-то сидела внутри монолитной базы, теперь поднимается наверх — в резолверы GraphQL.
И цифры это подтверждают: среди сервисов, делающих GraphQL-запросы, 55% выполнений содержат больше 10 дочерних resolve-спанов, а некоторые обрабатывают свыше 100 резолвов на один запрос. Медианный graphql.execute занимает около 200 мс, тогда как отдельный graphql.resolve — примерно 40 мс. Разница — это и есть цена «сборки» данных из кучи источников вместо одного join.
Компания, которая разнесла данные по нескольким базам, в итоге вынуждена строить отдельный слой, чтобы эти данные снова собрать. Это та работа, которую раньше делала одна база данных.
Где это особенно болит — маленькие компании
Есть нюанс, который легко упустить: те, кто использует пять и больше баз, — это в основном средние и крупные организации. Средние часто строились «с нуля» на микросервисах, крупные мигрировали с монолитов и оптимизируют разные нагрузки разными инструментами.
Маленькая команда в эту картину вписывается плохо. Для неё зоопарк из трёх-пяти баз означает не «гибкость», а конкретные проблемы:
- На каждого человека — по хранилищу. Когда в команде пять разработчиков и три базы, за каждой надо следить, бэкапить, обновлять, тюнить. Эксплуатация съедает больше, чем даёт гибкость.
- Интеграция становится отдельным проектом. GraphQL-слой, очереди сообщений, data warehouse — всё это инфраструктура, которую кто-то должен строить и поддерживать. Для стартапа это роскошь, а не необходимость.
- Джойны никуда не делись — они просто переехали и подорожали. Вместо одного SQL-запроса — цепочка резолверов, кэшей и батчингов.
Микросервисы задумывались как способ упростить независимость команд. Но в контексте данных они часто переносят сложность из базы — в приложение и в интеграционную обвязку.
Что из этого следует
Одна база навсегда — тоже не истина. Вопрос в том, оправдана ли множественность баз на текущем масштабе. Практические выводы:
- Не начинайте с зоопарка. Одна хорошо выбранная база (чаще всего PostgreSQL) покрывает 90% задач маленькой команды. Менять её стоит, когда появится конкретная нагрузка, которую она перестала вытягивать, — а не «на будущее».
- Считайте стоимость интеграции заранее. Каждая новая база — это будущий join через приложение, а значит, GraphQL-слой или ETL. Это не бесплатно.
- GraphQL — это симптом, а не решение. Если вам понадобился слой, который сшивает данные из нескольких хранилищ, честный вопрос: а нужны ли были все эти хранилища?
Вывод Datadog звучит мягко: «микросервисы сделали спор SQL против NoSQL неактуальным». Но из этих же данных следует более жёсткий тезис для малых команд: разнообразие баз данных — не самоцель, а цена за масштаб, которого у маленькой команды, возможно, ещё нет. Прежде чем переносить join из базы в резолверы GraphQL, стоит спросить: зачем данные разнесены туда, откуда их теперь нужно собирать обратно?
Top comments (0)