La documentation de Cassandra déclare,
N'utilisez pas d'index dans ces situations:
- Sur les colonnes à cardinalité élevée, car vous interrogez ensuite un énorme volume d'enregistrements pour un petit nombre de résultats. Voir Problèmes d'utilisation d'un index de colonne à cardinalité élevée ci-dessous.
Ça continue,
Si vous créez un index sur une colonne à cardinalité élevée, 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 de chansons, rechercher des chansons par auteur (une valeur généralement unique pour chaque chanson) plutôt que par leur artiste, 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é de 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 vers la table ayant une colonne indexée est modéré et n'est pas sous une charge constante.
Mais ne répond jamais vraiment à la question: pourquoi est-il inefficace? Je n'ai aucune idée de ce que signifie "le maintien manuel de la table comme une forme d'index". Mais ensuite, il se contredit quelque peu avec "... il est parfois très judicieux d'utiliser un index pour des raisons de commodité tant que le volume de la requête est modéré ..."
Est-ce juste essayer de me dire d'utiliser le PK quand et où je peux? Quelle est l'inefficacité? D'après ce que je comprends, une requête qui atteindrait un index devrait interroger tous les nœuds du cluster, puis chaque nœud ferait une recherche dans son index local et les résultats seraient ensuite agrégés. Ce n'est pas nécessairement cher (chaque recherche d'index doit être assez bon marché) sauf que nous payons en latence réseau, car nous devons attendre le nœud le plus lent du lot. Suis-je en train de manquer quelque chose ici?
Mais si j'ai une collection qui a un bajillion d'articles qui - en de rares occasions - doivent être recherchés par un attribut différent mais presque unique… c'est une utilisation appropriée, non?
¹Tout? IDK si la réplication signifie que cela peut toucher 1/3 du cluster pour un facteur de réplication de 3 ou non?