Блог

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

1. Запрос объектов PartitionKey RowKey и иногда дополнительная фильтрация
2. Обработка результирующего сегмента
3. Повторение этого до тех пор, пока continuationtoken== null

Запускается функцией Azure (V2), Windows.Azure.Хранилище 9.3.1.

Проблема, с которой мы сталкиваемся, заключается в том, что возвращаемые сегменты ExecuteQuerySegmentedAsync различаются по размеру примерно от 200 ~ до 700 ~ объектов. Я смог воспроизвести это только с помощью простого запроса PartitionKey , без дополнительной фильтрации. См:

Состояния документации ExecuteQuerySegmentedAsync могут возвращать до 1 тыс. объектов. Есть идеи относительно того, почему мы не набираем это число? Это (ожидаемо) значительно повысило бы производительность.

Обновление: максимальное время запроса в 5 секунд не достигнуто, получение сегмента занимает около 200-300 мс.

В документации указано, что ExecuteQuerySegmentedAsync может возвращать до 1 тыс. объектов. Есть идеи относительно того, почему мы не набираем это число?

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

Из этого link :

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