В сценарии, где у нас есть 1000 записей (уникальных ключей), вводящих космос в минуту, безопасно ли использовать / id в качестве ключа раздела?
В частности, существует концепция логических разделов https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data Графика здесь немного пугает меня, показывая, что логические разделы являются реальными объектами (например, "city": "London"),Если у меня 8-часовой TTL и 1000 записей в минуту, я не обязательно хочу 480 000 логических разделов, которыми должен управлять космос.
Я предполагаю, что происходит то, что значение ключа раздела просто хэшируется и по модулю с количеством физических разделов, напр.https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview#choose-partitionkey указывает, что это верно в разделе «Управление логическими разделами».Кроме того, в разделе «Выбор ключа раздела» предлагается (но на самом деле не говорится), что / id будет фантастическим ключом раздела, так как ему не нужно беспокоиться о пределе 10 ГБ, о пропускной способности, об отсутствии горячих точек, о широкой (огромный) диапазон значений, и, поскольку приложению не нужно фильтровать что-либо, кроме идентификатора, запросы с несколькими разделами не будут проблемой для этого варианта использования.
В заключение, нужно ли беспокоиться о накладных расходах памяти / ЦП и т. Д. Сотен тысяч значений ключа раздела (логических разделов)?Документы указывают, что чем больше значений ключа раздела, тем лучше, но не говорите, возможно ли иметь слишком много значений.