Поделиться через

Чтение канала изменений Azure Cosmos DB

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

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

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

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

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

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

  • Считывание изменений по определенному ключу раздела.
  • необходимость в управлении скоростью, с которой клиент получает изменения для обработки;
  • однократное чтение существующих данных в ленте изменений (например, для переноса данных).

Чтение фида изменений с помощью модели передачи данных

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

Функции Azure

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

Разработка с помощью Azure Functions — это простой процесс и может быть быстрее, чем развертывание обработчика потока изменений самостоятельно. Триггеры можно создавать с помощью портала Функций Azure или программно с помощью пакетов SDK. Visual Studio и VS Code обеспечивают поддержку для написания Функций Azure. Для кроссплатформенной разработки можно даже использовать CLI Функций Azure. Вы можете написать и отладить код на рабочем столе, а затем развернуть функцию с помощью одной кнопки. Дополнительные сведения см. в статьях Обработка бессерверной базы данных с помощью Функций Azure и Использование канала изменений вместе с Функциями Azure.

Библиотека обработчика канала изменений

Поддерживаемые SDK

.Net V3 Ява Node.JS Питон
✓ ✓ ✕ ✕

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

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

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

Как и в случае с Функциями Azure, разработка с использованием библиотеки обработчика потока изменений очень проста. Однако вы несете ответственность за развертывание одного или более узлов для процессора потока изменений. Хост — это экземпляр приложения, который использует процессор канала изменений, чтобы отслеживать изменения. Хотя Функции Azure имеют возможности автоматического масштабирования, вы несете ответственность за масштабирование хостов. Дополнительные сведения см. в разделе Использование обработчика канала изменений. Библиотека обработчика канала изменений входит в состав Azure Cosmos DB SDK версии 3.

Чтение канала изменений с использованием модели выборки

Модель получения потоков изменений позволяет использовать поток изменений в удобном для вас темпе. Изменения должны запрашиваться клиентом, и автоматический опрос изменений не выполняется. Если вы хотите навсегда "закрепить" последнее обработанное изменение (аналогично арендному контейнеру модели push-уведомлений), необходимо сохранить маркер продолжения.

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

  • Чтение изменений для всего контейнера.
  • Читайте изменения для конкретного диапазона ленты FeedRange.
  • Чтение изменений для определенного значения ключа раздела.

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

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

Канал обновлений в API-интерфейсах для Cassandra и MongoDB

Функции канала изменений отображаются как потоки изменений в API для MongoDB и запрос с предикатом в API для Cassandra. Дополнительные сведения о реализации API для MongoDB см. в разделе Потоки изменений в Azure Cosmos DB для MongoDB.

Собственный Apache Cassandra обеспечивает сбор измененных данных (CDC), механизм для указания определенных таблиц, чтобы сохранить их для архивации и отклонить записи в эти таблицы после достижения настраиваемого объема памяти на диске для журнала CDC. Функция канала изменений в Azure Cosmos DB для Apache Cassandra улучшает возможность запроса изменений с предикатом с помощью CQL. Дополнительные сведения о реализации см. в ленте изменений в Azure Cosmos DB для Apache Cassandra.

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

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