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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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