Каково влияние на RU CosmosDB при использовании проекций в запросах MongoAPI

Я не могу найти никакой информации о том, относится ли размер элемента к исходному размеру документа или к размер результата запроса после проецирования.

Я могу заметить, что такие простые запросы, как эти

 documents.find({ /*...*/ }, { name: 1 })

потребляют более 1000 RU, для результатов 400 элементов (поля запроса индексируются). Оригиналы документов довольно большие, около 500 кб. Фактически полученные данные крошечные из-за проекции. Если я удалю проекцию, запрос выполняется несколько секунд, но не потребляет значительно больше RU (на самом деле это немного больше, но, похоже, это связано с тем, что он разделен на большее количество GetMore вызовов).

введите описание изображения здесь

Мне кажется очень странным, что стоимость запроса в основном зависит от размера исходного документа в коллекции, а не от полученных данных. Это действительно так? Могу ли я уменьшить стоимость этого запроса без разделения данных на несколько коллекций? Логика в основном такова: просто получите «имя» всех этих больших документов в коллекции.

(Нет разбиения на БД ...)


azure azure-cosmosdb azure-cosmosdb-mongoapi
person hansmaad    schedule 22.02.2021    source источник
comment
Непонятно, что вы подразумеваете под простыми запросами - вы не указали тип find() операции, которую выполняете, или то, как вы устанавливаете индексы. Возможно, было бы полезно отредактировать свой вопрос и поделиться более подробной информацией.   -  person David Makogon    schedule 23.02.2021
comment
Кроме того, непонятно, что вы имеете в виду под запретом разбиения на разделы в базе данных - как вы избегаете разбиения на разделы?   -  person David Makogon    schedule 23.02.2021

Ответы (1)


arrow_upward
1
arrow_downward

К сожалению, Microsoft, похоже, не публикует свою формулу для определения стоимости RU, а только общие описания. Они действительно говорят о соображениях RU :

По мере увеличения размера элемента количество единиц RU, используемых для чтения или записи элемента, также увеличивается.

Таким образом, стоимость зависит от исходного размера элемента, а не только от его части, выводимой в результате операции чтения. Если вы используете Data Explorer для выполнения некоторых запросов и проверки статистики запросов, вы увидите две метрики: Retrieved Document Size и Output Document Size. Проектируя подмножество свойств, вы уменьшаете размер вывода, но не размер извлекаемого. В тестах на моих данных я вижу очень небольшое уменьшение заряда RU при выборе возвращаемых свойств - определенно не экономия пропорционально уменьшенному выходу.

По сути, уменьшение размеров элементов - это, вероятно, самая важная вещь, над которой нужно работать, как с точки зрения размера данных о свойствах, так и с точки зрения количества свойств. Вам определенно не нужны элементы размером 500 КБ, если вы можете этого избежать.

person Noah Stahl    schedule 23.02.2021
comment
You definitely don't want 500 KB items if you can avoid it. с точки зрения затрат, или это общий совет? Я не вижу смысла не хранить весь документ в БД, основанной на документах. Все запросы, команды, агрегаты работают отлично и производительно, просто они слишком дороги. Но большое спасибо за ваш ответ;) Я спрошу команду MS, почему запрос, который выполняется в несколько миллисекунд, стоит так же, как запрос, который выполняется в 100 раз дольше ... - person hansmaad; 23.02.2021
comment
Они слишком дороги. Это принципиально верно, чем больше ваши предметы, независимо от того, что еще вы пытаетесь оптимизировать. Если вас не волнуют расходы, не о чем беспокоиться, пока вы не достигнете предела в 2 МБ. - person Noah Stahl; 23.02.2021