web-dev-qa-db-fra.com

Implications de l'utilisation de / id pour la clé de partition dans CosmosDb

Dans le scénario où nous avons 1000 entrées (clés uniques) entrant dans le cosmos par minute, est-il sûr d'utiliser/id comme clé de partition?

En particulier, il y a le concept de partitions logiques https://docs.Microsoft.com/en-us/Azure/cosmos-db/partition-data Le graphique ici me fait un peu peur, montrant que les partitions logiques sont des entités réelles (Ex. "ville": "Londres"). Si j'ai 8 heures TTL et 1000 entrées par minute, je ne veux pas nécessairement 480 000 partitions logiques que le cosmos doit gérer.

Ce que j'imagine, c'est que la valeur de la clé de partition est simplement hachée et modulo avec le nombre de partitions physiques, ex. https://docs.Microsoft.com/en-us/Azure/cosmos-db/partitioning-overview#choose-partitionkey indique que cela est vrai dans la section "Logical Partition Mangement". De plus, la section "Choisir une clé de partition" suggère (mais n'indique pas réellement) que/id serait une clé de partition fantastique, car il n'a pas à se soucier de la limite de 10 Go, de la limite de débit, pas de points chauds, large ( énorme) plage de valeurs, et puisque l'application n'a pas besoin de filtrer sur quoi que ce soit sauf l'id, les requêtes de partition croisée ne seront pas un problème pour ce cas d'utilisation.

En résumé, dois-je m'inquiéter de la surcharge mémoire/CPU/etc de centaines de milliers de valeurs de clé de partition (partitions logiques)? Les documents indiquent que plus de valeurs de la clé de partition est meilleure, mais ne dites pas s'il est possible d'avoir trop de valeurs.

azureazure-cosmosdb
10
user2770791

Je fais partie de l'équipe d'ingénierie de Cosmos DB.

Vous n'avez pas à vous soucier du nombre de clés de partition logique créées sur une collection/conteneur Cosmos DB. Tant que la clé de partition est un choix approprié pour vos écritures (sous réserve d'un plafond de clé de partition par logique de 10 Go) et vos requêtes, vous devriez être bon.

10
Krishnan Sundaram

Les implications sont:

  1. meilleure cardinalité

  2. lecture facile et rapide et bon marché de documents

  3. aucune transaction car la portée de la transaction est la clé de partition

  4. les requêtes par autre chose que id seront des partitions croisées

PS. Je peux difficilement imaginer le cas pour n'avoir besoin de rien d'autre que de id lectures/requêtes. sauf peut-être pour la mise en cache des documents (combinée avec TTL).

0
dee zg