Cassandra: choisir une clé de Partition
Je ne sais pas s'il est préférable, du point de vue de la performance, d'utiliser une valeur de colonne commune (comme Country) comme clé de partition pour une clé primaire composée ou une valeur de colonne assez unique (comme Last_Name).
en regardant la documentation de Cassandra 1.2 sur les index j'obtiens ceci:
"Quand utiliser un index: Les index intégrés de Cassandra sont les meilleurs sur une table ayant beaucoup de lignes qui contiennent la valeur indexée. le plus unique les valeurs qui existent dans une colonne particulière, plus vous avoir, en moyenne, à interroger et à maintenir l'index. Par exemple, supposons que vous ayez une table user avec un milliard d'utilisateurs et voulait voir des utilisateurs par l'état dans laquelle ils vivaient. de nombreux utilisateurs partageront la même valeur de la colonne pour l'état (comme CA, NY, TX, etc.). Ce serait un bon candidat pour un index."
"Quand ne pas utiliser un index: Ne pas utiliser un index pour interroger un énorme volume de dossiers pour un petit nombre de résultats. Par exemple, si vous créez un index sur une colonne qui a beaucoup de valeurs distinctes, une requête entre les champs de subir beaucoup cherchent à obtenir très peu de résultats. dans le tableau avec un milliard d'utilisateurs, la recherche d'utilisateurs par leur adresse e-mail (une valeur qui est généralement unique pour chaque utilisateur) au lieu de leur état, est susceptible d'être très inefficace. Il serait probablement plus efficace manuellement maintenir la table sous la forme d'un index au lieu d'utiliser le Cassandra intégré dans l'indice. Pour les colonnes contenant des données uniques, il est parfois une bonne performance-sage d'utiliser un indice pour la commodité, aussi longtemps que le le volume de requête à la table ayant une colonne indexée est modérée et non sous charge constante."
en regardant les exemples de CQL, sélectionnez
"interrogation des clés primaires composées et tri des résultats", je vois quelque chose comme un UUID utilisé comme clé de partition... ce qui indiquerait qu'il est préférable d'utiliser quelque chose de plutôt unique?
3 réponses
L'indexation dans la documentation que vous avez rédigée renvoie à des index secondaires. Dans cassandra il y a un différence entre les indices primaire et secondaire. Pour un indice secondaire, il serait en effet mauvais d'avoir des valeurs très uniques, mais pour les composantes d'une clé primaire, cela dépend de la composante sur laquelle nous nous concentrons. Dans la clé primaire, nous avons ces composants:
clé primaire (clé de partitionnement, clé de clustering_1 ... clustering key_n)
la clé de partitionnement est utilisée pour distribuer des données à travers différents noeuds, et si vous voulez que vos noeuds soient équilibrés (c.-à-d. des données bien réparties à travers chaque noeud) alors vous voulez que votre clé de partitionnement soit aussi aléatoire que possible. C'est pourquoi l'exemple que vous avez utilise Uuid.
la touche clustering est utilisée pour la commande de sorte que les colonnes de recherche avec une clé de clustering particulière peuvent être plus efficaces. C'est où vous voulez que vos valeurs ne pas être unique et où il y aurait un succès de performance si les rangées uniques étaient fréquentes.
CQL docs avoir une bonne explication de ce qui se passe.
si vous utilisez cql3, compte tenu d'une famille de colonne:
CREATE TABLE table1 (
a1 text,
a2 text,
b1 text,
b2 text,
c1 text,
c2 text,
PRIMARY KEY ( (a1, a2), b1, b2) )
);
en définissant clé primaire ( (a1, a2, ...), b1, b2,... )
Cela implique que:
a1, a2,... sont des champs utilisés pour élaborer une touche de ligne pour:
- déterminer comment les données sont partitionnées
- déterminer ce qui est personnes à mobilité stockées sur une seule ligne
- visés en tant que touche de ligne ou de la partition de la clé
b1, b2,... sont famille de colonne les champs utilisés pour regrouper une touche de ligne pour:
- créer des ensembles logiques à l'intérieur d'une seule ligne
- permettent des schémas de recherche plus flexibles tels que la portée
- appelée clé de colonne ou clé de regroupement
tous les champs restants sont effectivement multiplexés / dupliqués pour chaque combinaison possible de touches de colonne. Ci-dessous un exemple de travail sur les clés composites avec des clés de partition et des clés de clustering.
Si vous voulez pour utiliser les requêtes de portée, vous pouvez utiliser des index secondaires ou (à partir de cql3) vous pouvez déclarer ces champs comme des clés de regroupement. En termes de vitesse de les avoir comme clé de regroupement créera une rangée large simple. Cela a un impact sur la vitesse puisque vous allez récupérer plusieurs valeurs clés de clustering telles que:
select * from accounts where Country>'Italy' and Country<'Spain'
je suis sûr que vous auriez eu la réponse, mais cela peut vous aider à mieux vous comprendre.
CREATE TABLE table1 (
a1 text,
a2 text,
b1 text,
b2 text,
c1 text,
c2 text,
PRIMARY KEY ( (a1, a2), b1, b2) )
);
ici les clés de partition sont (a1, a2) et les clés de ligne sont b1,b2.
combinaison des clés de partition et des clés de ligne doit être unique pour chaque nouvelle entrée d'enregistrement.
la clé primaire ci-dessus peut être définie comme ceci.
Node< key, value>
Node<(a1a2), Map< b1b2, otherColumnValues>>
comme nous le savons Clé De Partition est responsable de la distribution des données à travers votre nœud.
donc si vous insérez 100 enregistrements dans le Tableau1 avec les mêmes clés de partition et différentes clés de ligne. il stockera les données dans le même noeud mais dans des colonnes différentes.
logiquement nous pouvons représenter comme ceci.
Node<(a1a2), Map< string1, otherColumnValues>, Map< string2, otherColumnValues> .... Map< string100, otherColumnValues>>
ainsi l'enregistrement sera stocké séquentiellement en mémoire.