Когда данных и нагрузки становится столько, что одна база на одном сервере уже не тянет, а пользователи разбросаны по всему миру, встаёт вопрос: как масштабировать базу и держать низкую задержку везде? В Azure ответ на этот случай — Cosmos DB, глобально распределённая база. Разберём, что это и когда её брать вместо обычной управляемой PostgreSQL.

Что такое Cosmos DB

Cosmos DB — это управляемая NoSQL-база, которая автоматически распределяет данные и умеет реплицироваться в несколько регионов мира одним переключателем. Её сильные стороны — предсказуемо низкая задержка при любом масштабе и глобальное распространение: пользователь в каждом регионе читает из ближайшей копии.

Ещё одна особенность — много моделей и API. Cosmos DB умеет прикидываться разными базами: основной API — документный (Core/NoSQL), но есть совместимость с MongoDB, Cassandra, Gremlin (графы) и Table. Это позволяет переносить приложения, написанные под эти базы, почти без изменений. Ближайший аналог в AWS — DynamoDB, но Cosmos шире по моделям доступа и изначально заточен под глобальное распространение.

Ключ секционирования

Главное решение при проектировании Cosmos DB — ключ секционирования (partition key). Данные физически раскладываются по секциям на основе этого ключа, и от его выбора зависит всё: и производительность, и стоимость. Хороший ключ равномерно распределяет нагрузку; плохой создаёт «горячую» секцию, в которую бьёт весь трафик.

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

Уровни согласованности

Необычная для новичка вещь: в Cosmos DB согласованность настраивается. Между двумя крайностями — строгой согласованностью (всегда читаете самое свежее, но медленнее и дороже при глобальном распространении) и итоговой согласованностью (быстро и дёшево, но чтение может ненадолго отставать) — есть промежуточные уровни. Вы выбираете баланс под задачу: для баланса счёта нужна строгая, для ленты новостей хватит итоговой. Это прямой рычаг «скорость против свежести данных».

Единицы запросов (RU) и режимы

Стоимость и производительность Cosmos DB меряют в единицах запросов (Request Units, RU) — условная «цена» операции. Пропускную способность либо выделяют заранее (provisioned — предсказуемо при постоянной нагрузке), либо берут serverless — платите за фактические запросы, удобно для нерегулярной нагрузки и стартующих проектов.

Когда Cosmos DB, а когда PostgreSQL

Берите Azure Database for PostgreSQL, когда: классическое приложение, данные помещаются на один (пусть и мощный) сервер, нужны реляционная модель, сложные запросы и джойны, зрелая экосистема SQL. Разумный выбор по умолчанию для большинства сервисов.

Берите Cosmos DB, когда: нужен глобальный масштаб и низкая задержка в разных регионах, гибкая схема, огромные объёмы с предсказуемой задержкой по ключу. Типичные сценарии — глобальные пользовательские профили, каталоги, телеметрия, игровые данные.

Практический совет новичку: не берите Cosmos DB «на будущее». Если данные спокойно живут на одном сервере и вам нужны джойны — PostgreSQL проще и дешевле. Cosmos оправдывает себя именно там, где нужен глобальный масштаб и вы готовы проектировать под доступ по ключу.

Где это применяется

Cosmos DB закрывает нишу «глобальный масштаб и низкая задержка при гибкой схеме» — то, ради чего раньше приходилось вручную городить репликацию по регионам. В связке с serverless она особенно естественна: функция без сервера + база без сервера дают систему, которая масштабируется и тарифицируется по факту.

Типичные ошибки новичков:

  • берут Cosmos DB для маленького сервиса — там, где PostgreSQL проще и богаче;
  • плохо выбирают ключ секционирования — создают горячую секцию и упираются в неё;
  • оставляют строгую согласованность везде — переплачивают там, где хватило бы итоговой;
  • ждут привычного SQL с джойнами — это другая модель доступа.

Что учить дальше: обычные реляционные и кэширующие сервисы — в управляемых данных; как обращаться к базам из кода — в интеграции со Spring Boot; общие принципы выбора хранилища не привязаны к облаку — их разбирает системный дизайн. Сравнить подход можно с NoSQL-базой AWS — DynamoDB.