Clé de partition Azure Cosmos DB - la clé primaire est-elle acceptable?
Notre collection de base de données Azure Cosmos est devenue suffisamment grande pour nécessiter une clé de partition. En lisant un peu à ce sujet, j'ai l'impression que la meilleure clé de partition est celle qui permet une distribution uniforme et une cardinalité supérieure. Cet article de Microsoft en parle.
L'utilisation d'une clé primaire en tant que clé de partition permet une distribution uniforme, mais une cardinalité de 1 seulement. Si c'est ma seule option, s'agit-il d'une mauvaise chose? L'article susmentionné donne quelques exemples et semble indiquer que la clé primaire doit être utilisée comme clé de partition dans ces cas. Dans le cas de Azure Cosmos DB, les partitions sont logiques et non physiques. Cela ne conduirait donc pas à avoir chaque document sur son propre disque, mais il semblerait que cela puisse conduire à un index gonflé.
L'utilisation d'une clé primaire en tant que clé de partition est-elle une pratique courante? Y at-il des inconvénients à cela?
Non, il n'y a pas d'inconvénient à cela. S'efforcer d'avoir une clé de partition avec une cardinalité élevée. Ne vous inquiétez pas des index, des partitions physiques, etc.
Vous pouvez avoir des millions de clés de partition et 10 partitions physiques. Les partitions physiques sont créées en coulisse par CosmosDB. Vous ne devriez jamais vous soucier des partitions physiques.
En fait, le choix de la clé de partition est une question qui mérite d’être évaluée à plusieurs reprises. Étant donné que votre seule option est de choisir la clé primaire comme clé de partition, je viens de discuter de certaines des choses négatives possibles en tant que vos références.
En termes de performances, si le champ de votre requête n'est pas une clé de partition, votre requête réduira définitivement les performances de la requête en croisant des partitions. Sûrement, si la quantité de données est petite, cela n'aura pas beaucoup d'effet.
En termes de coût, la base de données cosmos est principalement facturée en fonction de l’espace de stockage et de la consommation en unités de stockage. Comme vous l’avez dit, choisir une clé primaire en tant que clé de partition entraînera davantage de stockage en index. Si la plupart des requêtes sont multi-partitions, cela entraîne également une consommation plus importante de RU.
En termes d'utilisation de procédure stockée, de déclencheurs ou de fichier UDF, vous ne pouvez pas utiliser de transactions entre partitions via des procédures stockées et des déclencheurs. Parce que sont ensuite partitionnés de sorte que vous devez spécifier la clé de partition (cardinalité est seulement 1) lorsque vous les utilisez.
Notez simplement que si une clé de partition est créée, elle ne peut pas être supprimée ou modifiée ultérieurement. Alors, réfléchissez-y avant de choisir et assurez-vous de sauvegarder les données.
Pour plus de détails, reportez-vous toujours au document officiel .
J'espère que ça vous aide.
Vous pouvez dire que la clé primaire est le choix le plus sûr et probablement le plus approprié pour une clé de partition.
Il garantit l'unicité de la valeur, ce qui est le seul moyen d'obtenir des résultats autres que des clés uniques. La distribution sera uniforme et, comme la clé primaire sera votre clé de partition, vous pourrez l'utiliser pour récupérer le document en le lisant au lieu de l'interrogation, ce qui réduit la vitesse et le coût de l'opération.