Запрос DocumentDB требует неожиданно высоких RU

У меня около 200 МБ данных, хранящихся в коллекции документов S3 (самая высокая). Размер каждого документа составляет около 300 КБ.

Но когда я запустил свой запрос, я с удивлением обнаружил, что для него требуется 7245,81 RU. Поскольку скорость S3 составляет 2500 RU / сек, эта производительность не масштабируется для моего приложения.

Я просто хочу спросить, делаю ли я что-нибудь не так и могу ли я что-нибудь сделать, чтобы это исправить?

Мой запрос такой:

SELECT item.Id,item.Priority, va.something, wa.something... 11 fields in total
FROM model.Item item 
JOIN va in item.Content.Children 
JOIN wa in va.Children 
WHERE item.State != 5

Я использую "Диапазон" в качестве типа индекса. Повлияет ли это на производительность этого запроса?


azure azure-cosmosdb
person Miaosen Wang    schedule 30.05.2015    source источник
comment
В документации говорится, что тип индекса Range разрешает запросы диапазона (с использованием ›,‹, ›=,‹ =,! =), Но вы можете попробовать WHERE item.State > 5 OR item.State < 5 Также попробуйте переключить его на хэш-индекс. Для одного значения я бы подумал, что хеш-индекс будет таким же эффективным или более эффективным, чем индекс диапазона.   -  person Larry Maccherone    schedule 30.05.2015

Ответы (1)


arrow_upward
2
arrow_downward

Запросы, использующие! =, Потребуют сканирования, поскольку нужно искать все записи индекса, чтобы исключить значения, которые не равны 5. Это приведет к высокому количеству RU. По возможности попробуйте переписать запрос как запрос на равенство или запрос диапазона.

  1. Если количество возможных значений item.State ограничено, например 1-10, то вы можете перечислить допустимые значения с помощью IN, то есть item.State IN (1,2,3,4,6,7,8, 9,10)
  2. Если это невозможно, используйте диапазоны, например, item.State> 5 OR item.State ‹5, как было предложено Ларри выше.

Надеюсь это поможет. Пожалуйста, напишите мне по адресу arramac на microsoft dot com, если вы хотите обсудить более подробно.

person Aravind Krishna R.    schedule 30.05.2015
comment
Использование IN решило мою проблему. RU упал до 194,71 Однако ›5 OR‹ 5 не помогло. Большое тебе спасибо! - person Miaosen Wang; 31.05.2015