Ключ раздела для DocumentDB

Question

У меня возник вопрос о выборе ключа раздела DocumentDB. У меня есть данные с UserId, DeviceId и WhateverId. Параметр UserId всегда будет в запросах, поэтому я выбрал UserId в качестве ключа раздела. Но у меня много данных для одного пользователя (миллионы объектов), и когда я сделал quety, как "SELECT * FROM c WHERE c.DeviceId = @DeviceId" с указанным ключом раздела, требуется много времени (около 6 минут для около 220 000 возвращенных объектов). Возможно, было бы более эффективным выбрать, например, DeviceId в качестве ключа раздела и делать запросы против нескольких разделов параллельно (с указанием EnableCrossPartitionQuery = true и MaxDegreeOfParallelism = количество разделов)? Или, может быть, это хорошая идея использовать отдельную коллекцию для каждого пользователя?

Answer 1

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

Вы можете поэкспериментировать с ключом раздела, чтобы улучшить parrallism, но, в лучшем случае, это обеспечит вам улучшение в 2-5 раз по сравнению с моим опытом. Этого достаточно?

Для более значительных улучшений вам обычно приходится прибегать к выборочной денормализации и/или кешированию.

Answer 2

Я знаю, что это немного старое, но на благо других, приезжающие в эту тему ...

Из вашего описания я полагаю, что эти устройства являются в основном уникальными для пользователя. Часто рекомендуется разделять что-то вроде userid, что хорошо, если у вас есть, скажем, приложение для колл-центра, со многими запросами для данного идентификатора пользователя и хотите найти не более нескольких сотен записей. В таких случаях данные могут быть быстро извлечены из одного раздела без накладных расходов при сопоставлении данных по разделам. Однако, если у вас есть миллионы записей для пользователя, то разделение на ИД пользователя, пожалуй, самый худший вариант, так как извлечение больших объемов данных из одного раздела скоро превысит накладные расходы на сортировку. В таких случаях вы хотите распределить данные пользователя как можно более равномерно по всем разделам. Если у каждого пользователя нет более 25 устройств с аналогичным использованием, то идентификатор устройства, вероятно, тоже не является хорошим выбором.

В таких случаях, как ваш, я обычно нахожу системный сгенерированный инкрементный ключ (например, идентификатор события или идентификатор транзакции), чтобы быть лучшим выбором.