Конструктивные шаблоны для каналов изменений в Azure Cosmos DB

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

Канал изменений Azure Cosmos DB обеспечивает эффективную обработку больших наборов данных с большим объемом операций записи. Также канал изменений позволяет обойтись без запросов ко всему набору данных, когда нужно найти только изменившиеся данные. В этой статье рассматриваются распространенные шаблоны проектирования веб-канала изменений, компромиссы по проектированию и ограничения канала изменений.

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

• Активация уведомления или вызова API при вставке, обновлении или удалении элемента.
• потоковая обработка в режиме реального времени (для Интернета вещей) или аналитическая обработка в режиме реального времени по рабочим данным;
• перемещение данных, такое как синхронизация с кэшем, поисковая система, хранилище данных или холодное хранилище.

Канал изменений в Azure Cosmos DB позволяет создавать эффективные и масштабируемые решения для каждого из этих шаблонов, как показано на следующем рисунке:

Вычисление и уведомления о событиях

Канал изменений Azure Cosmos DB может упростить сценарии, которые должны активировать уведомление или отправлять вызов в API при определенном событии. Обработчик веб-канала изменений можно использовать для автоматического опроса контейнера изменений, а затем вызова внешнего API каждый раз при записи, обновлении или удалении.

Вы также можете выборочно активировать уведомление или отправить вызов в API на основе определенного критерия. Например, если вы читаете из веб-канала изменений с помощью Функции Azure, вы можете поместить логику в функцию, чтобы отправить уведомление только в том случае, если условие выполнено. Хотя код функции Azure будет выполняться для каждого изменения, уведомление будет отправлено только в том случае, если условие выполнено.

Потоковая обработка в режиме реального времени

Канал изменений Azure Cosmos DB можно использовать для потоковой обработки в режиме реального времени (для Интернета вещей) или для аналитической обработки рабочих данных в режиме реального времени. Например, вы можете получать и хранить данные о событиях с устройств, датчиков, инфраструктуры и приложений, а затем обрабатывать эти события в режиме реального времени с помощью Spark. На следующем рисунке показано, как реализовать лямбда-архитектуру с помощью канала изменений Azure Cosmos DB:

Во многих случаях реализации потоковой обработки сначала получают большой объем входящих данных во временную очередь сообщений, например в концентраторы событий Azure или в Apache Kafka. Канал изменений — отличная альтернатива, поскольку Azure Cosmos DB поддерживает устойчивую высокую скорость приема данных с гарантированной низкой задержкой чтения и записи. Преимущества канала изменений Azure Cosmos DB перед очередью сообщений включают следующее.

Сохраняемость данных

Данные, записанные в Azure Cosmos DB, отображаются в канале изменений. Данные сохраняются в канале изменений, пока не будут удалены при чтении с помощью последней версии. Обычно очереди сообщений имеют максимальный срок хранения. Например, концентраторы событий Azure предлагают максимальный срок хранения данных 90 дней.

Возможность запроса

Помимо чтения из канала изменений контейнера Azure Cosmos DB, вы можете выполнять SQL-запросы к данным, хранящимся в Azure Cosmos DB. Канал изменений не является дублированием данных, которые уже есть в контейнере, но, скорее, это просто другой механизм чтения данных. Поэтому при чтении данных из канала изменений данные всегда соответствуют запросам одного контейнера Azure Cosmos DB.

Высокая доступность

Azure Cosmos DB обеспечивает доступность для чтения и записи до 99,999 %. В отличие от многих очередей сообщений, данные Azure Cosmos DB могут быть легко распределены глобально и настроены с целью восстановления (RTO) нулевой.

После обработки элементов в канале изменений можно создать материализованное представление и сохранить агрегированные значения обратно в Azure Cosmos DB. Если вы используете Azure Cosmos DB для создания игры, например, вы можете использовать канал изменений для реализации списков лидеров в режиме реального времени на основе показателей завершенных игр.

Перемещение данных

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

Например, с помощью канала изменений можно эффективно выполнять следующие задачи:

• Обновите кэш, индекс поиска или хранилище данных с данными, хранящимися в Azure Cosmos DB.

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

• реализация распределения данных по уровням и архивирования на уровне приложения. Например, можно хранить "горячие" данные в Azure Cosmos DB и переводить "холодные данные" в другие системы хранения, такие как хранилище BLOB-объектов Azure.

Если вам нужно выполнить денормализацию данных в разделы и контейнеры, данные можно считать из канала изменений контейнера как из источника для репликации данных. Репликация данных в режиме реального времени с каналом изменений может гарантировать только итоговую согласованность. Вы можете отслеживать, насколько далеко обработчик канала изменений отстает от обработки изменений в контейнере Azure Cosmos DB.

Источник событий

Шаблон источников событий включает использование хранилища, доступного только для добавления данных, для записи полного набора действий с этими данными. Канал изменений Azure Cosmos DB является отличным выбором в качестве центрального хранилища данных в архитектурах источников событий, в которых все приемы данных моделиируются как записи (без обновлений или удалений). В этом случае каждая запись в Azure Cosmos DB является "событием", поэтому в канале изменений есть полная запись прошлых событий. Типичные способы использования событий, опубликованных центральным хранилищем событий, предназначены для поддержания материализованных представлений или интеграции с внешними системами. Так как срок хранения в канале изменений не ограничен, вы можете воспроизвести все прошлые события, прочитав с самого начала канала изменений контейнера Azure Cosmos DB. Вы даже можете подписаться на один канал изменений нескольких потребителей канала изменений.

Azure Cosmos DB — это отличное центральное хранилище постоянных данных в шаблоне источников событий, доступное только для добавления. Оно отличается высокой горизонтальной масштабируемостью и высоким уровнем доступности. Кроме того, обработчик канала изменений предлагает гарантию "по крайней мере один раз" , гарантируя, что вы не пропускаете какие-либо события.

Текущие ограничения

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

Промежуточные обновления

Последний режим версии

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

Все версии и режим удаления (предварительная версия)

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

Операции удаления

Последний режим версии

Последняя версия канала изменений не записывает удаления. При удалении элемента из контейнера он также удаляется из канала изменений. Наиболее распространенным способом обработки удаления является добавление обратимого маркера на удаленные элементы. Можно добавить вызываемое deleted свойство и задать его true во время удаления. Это обновление документа отображается в канале изменений. Вы можете задать время жизни (TTL) на этом элементе, чтобы его можно было автоматически удалить позже.

Все версии и режим удаления (предварительная версия)

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

Хранение

Последний режим версии

Канал изменений в последнем режиме версии имеет неограниченное хранение. Если элемент существует в контейнере, он доступен в веб-канале изменений.

Все версии и режим удаления (предварительная версия)

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

Гарантированный порядок

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

Например, рассмотрим розничное приложение, использующее шаблон конструктора событий. В этом приложении различные действия пользователя — это все "события", которые моделироваются как записи в Azure Cosmos DB. Допустим, произошло несколько событий в следующей последовательности.

1. Клиент добавляет элемент A в корзину покупок.
2. Клиент добавляет элемент B в корзину покупок.
3. Клиент удаляет элемент A из корзины покупок.
4. Клиент проверяет содержимое корзины и отправляется.

Для каждого клиента сохраняется материализованное представление текущего содержимого корзины. Приложение должно обеспечивать обработку этих событий в том порядке, в котором они происходят. Например, если выгрузка корзины должна была быть обработана до удаления элемента A, скорее всего, элемент A был бы отправлен клиенту, а не элемент, который клиент хотел вместо этого, Item B. Чтобы гарантировать, что эти четыре события обрабатываются в порядке их возникновения, они должны находиться в том же значении ключа секции. Если выбрать username (у каждого клиента есть уникальное имя пользователя) в качестве ключа секции, вы можете гарантировать, что эти события отображаются в канале изменений в том же порядке, в котором они записываются в Azure Cosmos DB.

Примеры

Ниже приведены некоторые примеры кода веб-канала изменений в реальном мире для последнего режима версии, который выходит за рамки предоставленных примеров:

• Общие сведения о канале изменений
• Вариант использования IoT с применением канала изменений
• Вариант использования в сфере розничной торговли с применением канала изменений

Следующие шаги

• Просмотрите обзор канала изменений.
• Дополнительные сведения о режимах канала изменений.
• Узнайте о вариантах чтения веб-канала изменений.
• Если вы планируете ресурсы для миграции в Azure Cosmos DB, Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.
  • Если вам известно только количество виртуальных ядер и серверов в существующем кластере баз данных, прочитайте об оценке единиц запроса на основе числа виртуальных ядер или виртуальных ЦП.
  • Если вы знаете типичные ставки запросов для текущей рабочей нагрузки базы данных, ознакомьтесь с оценкой единиц запросов с помощью планировщика емкости Azure Cosmos DB.