Создание инкрементных отчетов с использованием таблиц Azure

Question

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

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

Оптимистичное решение, которое я нашел, это использовать механизм повтора: попробуйте обновить запись. Если вы получите код результата 412 (у вас нет последнего значения ETAG), повторите попытку. Это решение становится менее эффективным и более дорогостоящим, чем больше у вас пользователей, и чем больше данных необходимо обновлять одновременно (в моем случае именно).

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

Если у кого-то здесь есть несколько лучших практик в этом случае, я бы хотел его услышать.

Answer 1

Большинство облачных хранилищ (одно из них - хранилище таблиц) не обеспечивают масштабируемую запись на одном объекте/блоке/независимо. Для этого ограничения не существует быстрого исправления, поскольку это ограничение связано с основным компромиссом, создаваемым для создания облачного хранилища.

В основном, единица хранения (сущность/blob/безотносительно) может обновляться примерно каждые 20 мс, и это все об этом. Наличие специального работника или нет ничего не изменит в этом аспекте.

Вместо этого вам необходимо обратиться к своей задаче под другим углом. Для счетчиков наиболее обычным подходом является использование sharded counters (ссылка предназначена для GAE, но вы можете реализовать эквивалентное поведение на Azure).

Кроме того, еще один способ облегчить боль для асинхронной архитектуры ala CQRS, где ограничения производительности, которые вы устанавливаете на задержку обновления объектов, значительно ослаблены.

Answer 2

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

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