Справочник

Существует отношение "один-к-нескольким", где связанные данные ограничены, малы и часто считываются вместе.

→Встроить связанные данные в виде вложенного объекта или массива в основной документ.

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

Источник↗

Отношение "один-ко-многим", где сторона "много" неограниченно растет или обновляется независимо от стороны "один".

→Хранить связанные элементы как отдельные документы и использовать ID родительского документа в качестве ссылки.

Почему: Предотвращает превышение документами лимита в 2 МБ и избегает высоких затрат RU при обновлениях больших встроенных массивов.

Источник↗

Документ содержит массив, который со временем может неограниченно расти, рискуя превысить лимит размера документа в 2 МБ (например, журналы событий, комментарии).

→Разделить массив на несколько "корзинчатых" документов. Когда корзина достигает порогового значения размера/количества элементов, создать новую.

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

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

→Для ограниченных отношений дублируйте данные отношений с обеих сторон (например, встройте ID курсов в документ студента, ID студентов в документ курса). Для неограниченных используйте отдельный контейнер документов "соединение" или "граница".

Почему: Денормализация оптимизирует запросы в обоих направлениях (студенты в курсе, курсы для студента), не требуя объединений. Контейнер соединения используется для неограниченных случаев.

Моделирование иерархических данных (например, организационная структура, категории продуктов) и необходимость запроса всех потомков узла.

→Хранить массив всех ID или имен предков (путь) в каждом документе.

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

Документ имеет неограниченный массив (например, комментарии в блоге), но наиболее частый запрос требует только N последних элементов.

→Встроить подмножество последних элементов в основной документ и хранить все элементы как отдельные ссылочные документы.

Почему: Оптимизирует основной путь чтения для производительности и стоимости, при этом позволяя получать доступ ко всему набору данных при необходимости.

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

→Хранить события в одном контейнере, разбитом по ID сущности. Используйте Change Feed или Synapse Link для вычисления и хранения материализованных представлений или агрегатов.

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

Необходимо сохранить состояние связанных данных в определенный момент времени (например, адрес клиента в заказе).

→Встроить копию (снимок) связанных данных в документ, а не ссылаться на них.

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

Прием высокочастотных временных рядов данных (например, показания датчиков IoT) и запрос по устройству в определенных временных диапазонах.

→Использовать ID устройства в качестве ключа секции. Агрегировать показания в документы, сгруппированные по времени (например, почасовые или поминутные), вместо одного документа на каждое показание.

Почему: Резко сокращает количество документов и RU записи, одновременно сопоставляя данные для эффективных запросов по временным диапазонам в рамках одной секции.

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

→Использовать функцию TransactionalBatch SDK. Все операции должны быть нацелены на один и тот же логический ключ секции.

Почему: Предоставляет гарантии ACID для до 100 операций в пределах одной секции, гарантируя, что либо все операции успешно завершаются, либо все они завершаются сбоем.

Документы должны автоматически удаляться из контейнера по истечении определенного периода (например, 30 дней).

→Включить Time to Live (TTL) для контейнера и установить значение `ttl` по умолчанию в секундах (например, 2592000 для 30 дней). Значение `ttl` -1 для отдельного документа переопределяет значение по умолчанию и предотвращает истечение срока действия.

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

Необходимо хранить большие бинарные объекты (изображения, видео, документы > 2 МБ), связанные с метаданными Cosmos DB.

→Хранить бинарный объект в Azure Blob Storage. Хранить URI к блобу в документе Cosmos DB вместе с метаданными.

Почему: Cosmos DB оптимизирован для структурированных метаданных и имеет лимит размера документа в 2 МБ. Blob Storage — это экономичный и масштабируемый сервис для хранения больших объектов.

Одни и те же данные необходимо запрашивать по различным свойствам, что приводит к неэффективным кросс-секционным запросам (например, запросы заказов по клиенту, затем по продукту).

→Используйте Change Feed для заполнения второго контейнера (материализованного представления) теми же данными, но разбитыми по вторичному свойству запроса.

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

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

→Включить Azure Synapse Link для контейнера Cosmos DB. Выполнять аналитические запросы к аналитическому хранилищу контейнера, используя бессерверные пулы SQL или Spark Synapse.

Почему: Предоставляет облачное HTAP-решение без ETL. Запросы к колоночному аналитическому хранилищу не потребляют транзакционных RU и имеют высокую производительность.

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

→Использовать функцию Azure с триггером Cosmos DB. Триггер автоматически использует библиотеку Change Feed Processor.

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

Источник↗

Операция должна атомарно обновить базу данных и опубликовать сообщение в систему обмена сообщениями (например, Service Bus, Event Hubs).

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

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

Выбор ключа секции для нового контейнера для обеспечения производительности и масштабируемости.

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

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

Источник↗

Одно значение ключа секции получает непропорционально большой объем запросов, вызывая троттлинг ("горячую секцию").

→Создать синтетический ключ секции, конкатенируя исходный ключ со случайным суффиксом или другим свойством с высокой кардинальностью (например, `userId + "-" + random(1-10)`).

Почему: Распределяет нагрузку записи и чтения для одной логической сущности по нескольким физическим секциям, снижая троттлинг.

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

→Настроить иерархический ключ секции с упорядоченным массивом путей, например `["/tenantId", "/year"]`.

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

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

→Для простых перезаписей используйте Last-Writer-Wins (LWW). Для операций, требующих логики слияния (например, увеличение счетчика, обновление инвентаря), используйте пользовательскую политику разрешения конфликтов с хранимой процедурой слияния.

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

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

→По умолчанию используйте согласованность сессии (Session consistency) для хорошего баланса и чтения собственных записей. Используйте ограниченную устареваемость (Bounded Staleness) для предсказуемой задержки чтения. Переопределяйте определенные критические операции записи/чтения на строгую согласованность (Strong consistency) по мере необходимости.

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

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

→Переключиться с политики индексирования по умолчанию на пользовательскую политику. Явно включить пути для запрашиваемых свойств и исключить все остальные пути (`"/*"` в `excludedPaths`).

Почему: Каждое индексированное свойство влечет за собой затраты RU при записи. Исключение неиспользуемых свойств может значительно сократить потребление RU при записи и размер хранилища индекса.

Источник↗

Частый запрос фильтрует по одному свойству и сортирует по другому (например, `WHERE c.status = "active" ORDER BY c.timestamp DESC`).

→Создать составной индекс для свойств в том порядке, в котором они появляются в запросе: `(status ASC, timestamp DESC)` .

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

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

→Использовать проекцию запроса для выбора только необходимых свойств (например, `SELECT c.id, c.name FROM c`) вместо `SELECT *`.

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

Приложение часто опрашивает обновления документов, но данные изменяются нечасто, что приводит к высоким затратам RU на чтение.

→Сохранить ETag из последнего чтения. При последующих чтениях отправлять ETag в заголовке `If-None-Match`.

Почему: Если документ не изменился, Cosmos DB возвращает статус 304 Not Modified с минимальной платой RU (обычно ~1 RU), экономя затраты и пропускную способность.

Рабочая нагрузка имеет переменные или непредсказуемые шаблоны трафика со значительными пиками и спадами.

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

Почему: Автоматически масштабирует пропускную способность между 10% от максимума и максимальным RU/с на основе использования, оптимизируя затраты, не платя за простаивающую выделенную мощность.

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

→Использовать режим бессерверной емкости для учетной записи Cosmos DB.

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

Необходимо загрузить или изменить большое количество документов (от тысяч до миллионов) как можно быстрее.

→Использовать функцию массовой поддержки SDK (например, `AllowBulkExecution = true` в .NET SDK v3).

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

Хранимая процедура, обрабатывающая большой пакет документов, завершается по таймауту.

→Реализовать ограниченное выполнение. Хранимая процедура должна проверять, приближается ли она к 5-секундному лимиту выполнения, и, если да, возвращать токен продолжения клиенту. Затем клиент повторно вызывает процедуру с этим токеном для возобновления обработки.

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

Критически важное для бизнеса приложение требует высокой доступности с минимальной потерей данных (RPO) и быстрым временем восстановления (RTO) в случае регионального сбоя.

→Настроить учетную запись Cosmos DB с несколькими регионами записи и включить автоматическое переключение при отказе.

Почему: Обеспечивает наименьшие RPO и RTO. Данные реплицируются между регионами, и в случае сбоя Cosmos DB автоматически назначает вторичный регион новым основным регионом записи.

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

→Включить режим непрерывного резервного копирования для учетной записи Cosmos DB.

Почему: Непрерывное резервное копирование позволяет восстановить данные до любого момента времени (с точностью до секунды) в течение периода хранения (7 или 30 дней). Операция восстановления создает новую учетную запись.

Источник↗

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

→Настроить учетную запись Cosmos DB с ключами, управляемыми клиентом (CMK), используя ключ из Azure Key Vault.

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

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

→Использовать интеграцию Azure AD и назначить встроенную роль (например, Cosmos DB Built-in Data Reader) или пользовательскую роль RBAC, ограниченную конкретным контейнером или базой данных.

Почему: Устраняет необходимость управлять и совместно использовать мастер-ключи. RBAC обеспечивает аудируемый контроль доступа на основе идентификации.

Учетная запись Cosmos DB должна быть доступна только из определенной виртуальной сети Azure (VNet), без трафика через общедоступный интернет.

→Создать приватную конечную точку для учетной записи Cosmos DB в VNet и отключить доступ к общедоступной сети в настройках брандмауэра.

Почему: Приватные конечные точки предоставляют приватный IP-адрес для учетной записи Cosmos DB в вашей VNet, гарантируя, что весь трафик проходит через безопасную магистраль Azure.

Диагностика первопричины ошибок троттлинга HTTP 429 (Too Many Requests).

→Мониторить метрику "Normalized RU Consumption" в Azure Monitor. Использовать диагностические журналы (`CDBPartitionKeyRUConsumption`) для определения того, какие ключи секций потребляют больше всего RU.

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

Необходимо отслеживать задержку запросов и оповещать о ней для обеспечения соответствия SLA.

→Мониторить метрику "Server Side Latency P99" в Azure Monitor. Создать правило оповещения, если эта метрика превышает пороговое значение SLA.

Почему: Задержка P99 представляет наихудший сценарий для 99% запросов и является основой для SLA Cosmos DB. Это более значимый показатель проблем с производительностью, чем средняя задержка.

Требование соответствия предписывает, что все операции доступа к данным (чтение, запись, запросы) должны быть проверены.

→Включить диагностические настройки для учетной записи Cosmos DB и перенаправить категорию журналов `DataPlaneRequests` в рабочую область Log Analytics или учетную запись хранения.

Почему: Журнал `DataPlaneRequests` предоставляет подробную информацию о каждой операции с данными, включая тип операции, IP-адрес клиента и доступный ресурс, что важно для аудита безопасности.

Недоверенный клиент (например, мобильное приложение) нуждается во временном, ограниченном доступе к определенным ресурсам Cosmos DB (например, только к документам в своей собственной секции).

→Реализовать доверенный сервис среднего уровня, который аутентифицирует пользователя, затем использует мастер-ключ для генерации и возврата клиенту кратковременного, ограниченного по разрешениям токена ресурса.

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