Microsoft AZ-204: Azure Cosmos DB — Руководство по подготовке

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Часть Microsoft Azure Developer Associate AZ-204 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Azure Cosmos DB — это полностью управляемая, глобально распределенная, мультимодельная база данных, предназначенная для эластично масштабируемых приложений с низкой задержкой. Она предоставляет несколько API поверх общего механизма секционированного хранения и репликации, предлагает пять настраиваемых уровней согласованности и комплексные соглашения об уровне обслуживания (SLA) по доступности, задержке, пропускной способности и согласованности. Данные организованы в учетные записи, базы данных и контейнеры (или коллекции/таблицы/графы в зависимости от API). Контейнеры горизонтально секционируются и масштабируются по ключу секционирования, а все операции измеряются в единицах запросов (Request Units, RU) — нормализованной валюте, которая абстрагирует использование ЦП, IOPS и памяти.

API и программируемость

Cosmos DB поддерживает несколько API, совместимых на уровне протокола, что позволяет использовать нативные SDK и драйверы без переписывания модели данных:

API SQL (Core): Рекомендуемый вариант по умолчанию для новых рабочих нагрузок. Хранит документы JSON с поддержкой многофункциональных SQL-подобных запросов (SELECT, WHERE, ORDER BY, JOIN в пределах документа, агрегаты) и детерминированных пользовательских функций (UDF) для вычисляемых предикатов/проекций. Бизнес-логика на стороне сервера выполняется в виде хранимых процедур и триггеров (pre/post) на JavaScript в рамках одной логической секции, что обеспечивает транзакции ACID для нескольких элементов с общим ключом секционирования. TransactionalBatch предоставляет операции над несколькими элементами в одной секции. Точечные чтения (id + ключ секционирования) наиболее эффективны по потреблению RU. Создать клиент .NET можно с помощью кода, подобного этому:

undefined

API для MongoDB: Совместим на уровне протокола с MongoDB, что позволяет использовать стандартные драйверы и инструменты MongoDB (например, mongodump/mongorestore для миграции). Вы можете использовать функции MongoDB, которые поддерживаются механизмами распределения, автомасштабирования и SLA от Cosmos DB. Транзакции с несколькими документами поддерживаются в пределах одной логической секции; для строгой атомарности на уровне пользователя используйте нешардированную коллекцию или шардируйте по свойству, такому как username, чтобы связанные документы находились в одной секции.
API для Cassandra: Совместим с драйверами Apache Cassandra и CQL. Идеально подходит для шаблонов доступа для ширококолоночных баз данных и временных рядов. Вы получаете автоматическое глобальное распределение и масштабирование на основе RU вместо управления узлами.
API Gremlin: Модель графа свойств с запросами и обходами Gremlin из TinkerPop. Секционирование необходимо для распределения вершин и ребер для обеспечения масштабируемых обходов.
API таблиц: Модель «ключ-значение» с SDK и семантикой, совместимыми с Azure Table Storage, но с поддержкой глобального распределения, пропускной способности в RU и индексов с меньшей задержкой от Cosmos DB.

Общие операции SDK для всех API включают CRUD, оптимистичный параллелизм с помощью ETag, операции upsert (обновление или вставка), серверные сценарии (хранимые процедуры, триггеры) и UDF (для API SQL). Запросы параметризуются для снижения потребления RU и повышения безопасности. Массовые операции и потоковые API минимизируют накладные расходы на стороне клиента и затраты в RU при приеме данных с высокой пропускной способностью.

Согласованность, индексирование и семантика запросов

Cosmos DB предлагает пять четко определенных уровней согласованности для каждой учетной записи (во многих SDK их можно переопределить для каждого отдельного запроса):

Строгая (Strong): Линеаризуемость — операции чтения видят самую последнюю зафиксированную запись в глобальном масштабе. Максимизирует корректность, но ограничивает задержку записи и гибкость в выборе регионов; недоступна при включенной записи в несколько регионов.
Ограниченное устаревание (Bounded Staleness): Операции чтения отстают от записей не более чем на K версий или на время T. Гарантирует монотонный порядок чтения и записи; хороший компромисс для глобально распределенных операций чтения, которые допускают ограниченную задержку.
Сеанс (Session) (по умолчанию): В рамках сеанса обеспечивается чтение собственных записей (read-your-writes), запись после чтения (write-follows-reads) и монотонные чтения. Каждый клиент поддерживает токен сеанса; передача этого токена между узлами (например, через параметры запроса в SDK) сохраняет гарантию чтения собственных записей между этими узлами.
Согласованный префикс (Consistent Prefix): Операции чтения никогда не видят записи в неправильном порядке, но могут видеть только префикс журнала транзакций.
Согласованность в конечном счете (Eventual): Максимальная доступность и минимальная задержка без каких-либо гарантий порядка.

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

Исключить большие или интенсивно записываемые пути для снижения стоимости операций записи в RU.
Добавить составные индексы для поддержки эффективной сортировки (ORDER BY) по нескольким свойствам и запросов, сочетающих фильтры и сортировку по разным свойствам.
Добавить пространственные индексы для типов GeoJSON (Point, LineString, Polygon, MultiPolygon) и выполнять запросы с помощью пространственных функций, таких как ST_DISTANCE, ST_WITHIN и ST_INTERSECTS. Режим индексирования также можно установить в None для контейнеров, оптимизированных для записи, где чтение выполняется только по id/ключу секционирования. Различные API предоставляют доступ к индексированию через свои нативные парадигмы (например, конструкции драйверов MongoDB и Cassandra), но все они используют базовый механизм индексирования Cosmos.

Учитывайте размер элемента и форму запроса. API SQL накладывает ограничение на размер элемента (например, 2 МБ), а межсекционные запросы, большие проекции и сложные предикаты увеличивают потребление RU. Используйте выборочные проекции, подходящие фильтры и запросы, учитывающие секционирование, чтобы миними

Секционирование и пропускная способность (RU)

Cosmos DB разделяет логические и физические секции:

Логические секции группируют элементы по значению ключа секционирования. Все элементы с одинаковым ключом участвуют в транзакционных пакетах и серверных скриптах вместе.
Физические секции управляются сервисом и содержат множество логических секций. Пропускная способность (RU) и хранилище распределяются между физическими секциями; «горячие» логические секции могут стать узким местом для пропускной способности физической секции.

Выбирайте эффективный ключ секционирования с высокой кардинальностью и равномерным распределением доступа со временем. Хорошие ключи соотносятся с вашим основным путем доступа (например, userId, deviceId, tenantId или orderId). Избегайте ключей с низкой кардинальностью или сгруппированных по времени, которые вызывают перекос (например, country, status или day). Если ни одно свойство не подходит:

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

Модели пропускной способности:

Подготовленная пропускная способность: Резервируйте RU/с для контейнера или базы данных (разделяется между дочерними контейнерами). Предсказуемая производительность со стабильностью затрат. Масштабируйте вручную или через API/CLI.
Автомасштабирование: Установите максимальное значение RU/с; Cosmos DB эластично масштабируется в диапазоне от 10% до 100% от этого максимума в зависимости от нагрузки. Оплата взимается по максимальному значению RU, использованному за час; отлично подходит для переменных рабочих нагрузок и неизвестных пиков.
Serverless: Нет подготовленных RU/с; оплата за потребление RU каждой операции. Идеально для разработки, неравномерных или низкопроизводительных рабочих нагрузок без предсказуемой базовой линии.

Техники оптимизации RU включают точечные чтения по id+ключ секционирования, параметризованные запросы, выборочные проекции, денормализацию для сокращения шаблонов, подобных JOIN, и использование Change feed для производных представлений вместо сложных запросов к нескольким контейнерам. Используйте ETags с If-Match для управления параллелизмом, чтобы избежать дорогостоящих по RU повторных попыток. Отслеживайте метрики RU и троттлинг (HTTP 429) и реализуйте политики повторных попыток с джиттером в SDK.

Глобальное распределение и канал изменений

Готовое к использованию многорегиональное распределение Cosmos DB позволяет добавлять и удалять регионы в любое время. Все регионы доступны для чтения; включение многорегиональной записи позволяет выполнять одновременные операции записи повсеместно с задержкой чтения менее 10 мс на 99-м процентиле в ближайших регионах. Клиентские SDK следует настраивать с указанием предпочтительных регионов для локальной маршрутизации трафика и корректной отработки отказа. В .NET укажите предпочтительные регионы через CosmosClientOptions ApplicationPreferredRegions (или эквивалентный параметр в других SDK). Многорегиональная запись требует политики разрешения конфликтов:

Last Write Wins (Последняя запись побеждает): Используется путь разрешения конфликтов (например, свойство с меткой времени или версией). Если он не указан, может использоваться системная метка времени.
Пользовательское разрешение: Используется хранимая процедура слияния для детерминированного разрешения конфликтов.
Вручную: Проверка канала конфликтов и явное разрешение.

Канал изменений предоставляет упорядоченный журнал изменений только для добавления (append-only) для каждого ключа логической секции. Он идеально подходит для:

Архитектур, управляемых событиями, и CQRS (проецирование документов в оптимизированные для чтения представления).
Последующих конвейеров (загрузка в data lake, индексирование для поиска, инвалидация кэша).
Аналитики и аудита в режиме, близком к реальному времени. Существует два основных способа использования:
Библиотека Change Feed Processor: Распределенная, отказоустойчивая обработка, которая использует контейнер аренд (leases container) для балансировки секций между обработчиками и безопасного горизонтального масштабирования.
Модель извлечения (pull model) с FeedIterator: Явный перебор изменений с логикой контрольных точек под вашим управлением; разделение работы по FeedRange для распараллеливания. Azure Functions предлагает триггер Cosmos DB, который инкапсулирует шаблон обработчика для бессерверной обработки. Можно начать с самого начала или с «текущего момента», а полнофункциональный канал изменений (full-fidelity) фиксирует промежуточные обновления и удаления для создания полных журналов аудита. Проектируйте контейнер аренд с достаточной пропускной способностью и выбирайте идемпотентные обработчики для поддержки повторных попыток и доставки «как минимум один раз».

Практический сценарий

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

Выбрать Cosmos DB SQL (Core) API с многорегиональной записью

Почему: Core API предлагает широкие возможности для запросов и программирования на стороне сервера. Многорегиональная запись минимизирует задержку записи в глобальном масштабе и обеспечивает устойчивость к региональным сбоям без простоя на запись.

Определить ключ секции с высокой кардинальностью и иерархические ключи

Подход: Секционировать по userId; для чрезвычайно активных пользователей использовать иерархические ключи, такие как [“userId”, “bucket”], где bucket — это хэш-суффикс.
Почему: Равномерно распределяет нагрузку на чтение и запись, позволяет выполнять транзакционные обновления для каждого пользователя и избегает появления «горячих» секций.

Настроить автомасштабирование пропускной способности для основных контейнеров

Почему: Трафик зависит от времени суток и маркетинговых кампаний; автомасштабирование справляется со всплесками до настроенного максимального значения RU/s, при этом стоимость остается пропорциональной фактической нагрузке.

Установить уровень согласованности Session на уровне учетной записи

Почему: Мобильным клиентам для хорошего пользовательского опыта требуется согласованность «чтение собственных записей» (read-your-writes) без ограничений по задержке, присущих уровню Strong. Токены сеанса (Session tokens) передаются клиентами и уровнем шлюза для сохранения семантики сеанса между узлами.

Реализовать обработку канала изменений с помощью Azure Functions и Change Feed Processor

Подход: Создать приложение Functions с триггером Cosmos DB, привязанным к контейнеру взаимодействий. Использовать выделенный контейнер аренд (leases container) и включить несколько экземпляров для параллелизма.
Почему: Это обеспечивает отказоустойчивую, масштабируемую и не требующую значительных операционных затрат обработку для обновления материализованных представлений (например, контейнера рекомендаций) и публикации событий в Event Hubs для потоковой аналитики.

Создать производный контейнер рекомендаций с настроенной политикой индексирования

Подход: Исключить из индексации большие, интенсивно записываемые свойства; добавить составные индексы для (userId, score DESC) для поддержки запросов TOP-K.
Почему: Снижает стоимость операций записи в RU, обеспечивая при этом эффективный поиск с сортировкой для персонализированных лент.

Включить глобальное распределение с указанием предпочтительных регионов в SDK

Подход: Добавить регионы в North America, Europe и APAC. Настроить CosmosClientOptions с ApplicationPreferredRegions в зависимости от региона развертывания приложения.
Почему: Гарантирует, что операции чтения обслуживаются локально с задержкой менее 10 мс, а отработка отказа происходит прозрачно.

Настроить разрешение конфликтов и наблюдаемость

Подход: Использовать политику Last Write Wins с генерируемыми сервером логическими часами (свойство версии) для идемпотентных обновлений и направлять конфликты в очередь мониторинга для редких крайних случаев.
Почему: Гарантирует детерминированную сходимость при одновременных многорегиональных записях и обеспечивает операционную видимость.

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

← Azure Storage и хранилище BLOB-объектов · Все домены · Контейнерные решения Azure →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →