web-dev-qa-db-fra.com

Cassandra: choisir une clé de partition

Je ne sais pas s'il est préférable, en termes de performances, d'utiliser une valeur de colonne très partagée (comme Country) comme clé de partition pour une clé primaire composée ou une valeur de colonne plutôt unique (comme Last_Name).

En regardant la documentation de Cassandra 1.2 sur les index je reçois ceci:

" Quand utiliser un index : les index intégrés de Cassandra sont préférables sur une table comportant de nombreuses lignes contenant la valeur indexée. Plus il y a de valeurs uniques dans une colonne particulière, plus vous aurez en moyenne de surcharge pour interroger et maintenir l'index. Par exemple, supposons que vous disposiez d'une table utilisateur avec un milliard d'utilisateurs et souhaitaient rechercher les utilisateurs selon l'état dans lequel ils vivaient. De nombreux utilisateurs partageront la même valeur de colonne pour l'état (comme CA, NY, TX, etc.). être un bon candidat pour un index. "

" Quand ne pas utiliser d'index : n'utilisez pas d'index pour interroger un énorme volume d'enregistrements pour un petit nombre de résultats. Par exemple, si vous créer un index sur une colonne qui a de nombreuses valeurs distinctes, une requête entre les champs entraînera de nombreuses recherches pour très peu de résultats. Dans le tableau avec un milliard d'utilisateurs, recherchant les utilisateurs par leur adresse e-mail (une valeur qui est généralement unique pour chaque utilisateur) plutôt que par leur état, est susceptible d'être très inefficace. Il serait probablement plus efficace de maintenir manuellement la table sous la forme d'un index au lieu d'utiliser l'index intégré Cassandra. Pour les colonnes contenant des données uniques, il est parfois judicieux, en termes de performances, d'utiliser un index pour plus de commodité, tant que le volume de requête de la table ayant un la colonne indexée est modérée et n'est pas sous charge constante. "

En regardant les exemples de SELECT de CQL pour

" Interrogation des clés primaires composées et tri des résultats", je vois quelque chose comme un UUID utilisé comme clé de partition ... qui indiquerait qu'il est préférable d'utiliser quelque chose d'assez unique ?

enter image description here

cassandracomposite-primary-keydatabase-partitioningdatabase-indexes
23
andandandand

L'indexation dans la documentation que vous avez rédigée fait référence aux index secondaires. Dans cassandra il y a différence entre les index primaire et secondaire . Pour un index secondaire, il serait en effet mauvais d'avoir des valeurs très uniques, cependant pour les composants dans un clé primaire, cela dépend du composant sur lequel nous nous concentrons. Dans la clé primaire, nous avons ces composants:

CLÉ PRIMAIRE (clé de partitionnement, clé de cluster_1 ... clustering key_n)

La clé de partitionnement est utilisée pour distribuer des données sur différents nœuds, et si vous voulez que vos nœuds soient équilibrés (c'est-à-dire des données bien réparties sur chaque nœud), vous voulez que votre clé de partitionnement soit aussi aléatoire que possible. C'est pourquoi l'exemple que vous avez utilise des UUID.

La clé de clustering est utilisée pour classer afin que l'interrogation des colonnes avec une clé de clustering particulière soit plus efficace. C'est là que vous voulez que vos valeurs ne soient pas uniques et où il y aurait un impact sur les performances si des lignes uniques étaient fréquentes.

Les cql docs ont une bonne explication de ce qui se passe.

40
Lyuben Todorov

si vous utilisez cql3, étant donné une famille de colonnes:

CREATE TABLE table1 (
  a1 text,
  a2 text,
  b1 text,
  b2 text,
  c1 text,
  c2 text,
  PRIMARY KEY ( (a1, a2), b1, b2) )
);

en définissant une clé primaire ((a1, a2, ...), b1, b2, ...)

Ceci implique que:

a1, a2, ... sont des champs utilisés pour créer une clé de ligne afin de:

  • déterminer comment les données sont partitionnées
  • déterminer ce qui est stocké physiquement sur une seule ligne
  • appelé clé de ligne ou clé de partition

b1, b2, ... sont des champs de famille de colonnes utilisés pour regrouper une clé de ligne afin de:

  • créer des ensembles logiques à l'intérieur d'une seule ligne
  • permettre des schémas de recherche plus flexibles tels que la plage de plages
  • appelé clé de colonne ou clé de cluster

Tous les champs restants sont effectivement multiplexés/dupliqués pour chaque combinaison possible de clés de colonne. Ci-dessous un exemple sur les clés composites avec les clés de partition et les clés de cluster fonctionnent.

Si vous souhaitez utiliser des requêtes de plage, vous pouvez utiliser des index secondaires ou (à partir de cql3) vous pouvez déclarer ces champs comme clés de clustering. En termes de vitesse, les avoir comme clé de cluster crée une seule ligne large. Cela a un impact sur la vitesse, car vous récupérerez plusieurs valeurs de clé de cluster telles que:

select * from accounts where Country>'Italy' and Country<'Spain'

8
natbusa

Je suis sûr que vous auriez obtenu la réponse, mais cela peut tout de même vous aider à mieux 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.

la 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 entre vos nœuds.

Donc, si vous insérez 100 enregistrements dans table1 avec les mêmes clés de partition et différentes clés de ligne. il stockera les données dans le même nœud mais dans différentes colonnes.

logiquement, nous pouvons représenter comme ça.

Node<(a1a2), Map< string1, otherColumnValues>, Map< string2, otherColumnValues> .... Map< string100, otherColumnValues>>

Ainsi, l'enregistrement sera stocké séquentiellement en mémoire.

1
Aftab