Azure Функции обновления сущности Table Storage, проблема параллелизма

Question

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

I создаю импорт с Azure функциями. Функция запускается, когда BLOB загружается в контейнер хранения BLOB. Функция читает файл и передает каждую запись импорта в очередь проверки. При сбое проверки объект будет передан в очередь ошибок. Когда проверка завершится успешно, объект будет поставлен в очередь в очереди успеха.

Другая функция считывает очередь успеха и начинает запись объектов в хранилище таблиц. При сбое этого процесса объект будет поставлен в очередь на ошибку.

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

На мой взгляд, это лучший способ реализовать процедуру импорта с функциями. Это много функций, я знаю ... Но все они несут одну ответственность (например, чтение файла, проверка и т. Д. c и т. c).

Теперь моя проблема в том, когда объект сохранен успешно ИЛИ когда неудачный объект сохранен успешно, я также отправляю сообщение в очередь состояний, сообщающее, что импорт для определенного объекта успешно завершен или нет. Другая функция Azure обрабатывает эту очередь состояния и обновляет ОДНУ запись в таблице хранения с последним статусом. Статус для импорта выглядит так:

CorrelationId <-- The import identifier
StartedAt (date time)
TotalEntries (int)
Succeeded (int)
Failed (int)
CompletedAt (date time)

Очевидно, что Успешное или Неудачное int увеличивается на единицу для каждого сообщения в очереди. Кроме того, когда размер очереди увеличивается, количество экземпляров функций AZ увеличивается, и другие функции начинают обновлять запись в хранилище таблицы одновременно, что приводит к ошибкам. Я могу выбрать использование ETag, что приводит к сбою некоторых записей в очереди (и это медленно !!), или я могу установить ETag в «*», что делает процесс намного быстрее, но тогда я просто пропускаю данные. Как вы должны справиться / решить такую ​​ситуацию?

Спасибо большое!

Answer 1

Azure Хранение таблиц - не лучший вариант для обработки сценариев этого типа. Вам следует создать материализованное представление в SQL базе данных или базе данных Cosmos, которая лучше обрабатывает параллелизм / транзакции.

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

Answer 2

Не совсем ответ на ваш вопрос, но подумайте о нем, как о «пище для размышлений»:).

Что вы можете сделать, это создать таблицу (назовем ее StatusTracker), где вы будете сохранить статус каждой операции. Это будет простая таблица с PartitionKey в виде тиков (или обратных тиков), представляющих дату / время (вы можете установить ее на детализацию минут, чтобы данные за одну минуту сохранялись в одном разделе), RowKey как уникальные идентификатор операции, а затем атрибут состояния, который сообщает вам, была ли операция неудачной или успешной. Вы можете использовать эту таблицу для обеспечения обратной связи с пользователем в режиме реального времени. Поскольку вы всегда вставляете записи в эту таблицу, вы не столкнетесь с проблемами параллелизма.

Тогда вы можете написать другую функцию (О нет! ... Не другую функцию :)), которая будет запускаться по таймеру ( работает каждые 5 минут например). То, что он будет делать, это запросить первую таблицу (StatusTracker), суммировать данные и обновить таблицу состояния. Поскольку эта таблица обновляется только одной функцией, опять же, вы не столкнетесь с проблемами параллелизма.