Partager via

Indexation secondaire dans Azure Cosmos DB for Apache Cassandra

  • Article

S’APPLIQUE À : Cassandra

L’API pour Cassandra dans Azure Cosmos DB tire parti de l’infrastructure d’indexation sous-jacente pour exposer la force d’indexation inhérente à la plateforme. Toutefois, contrairement à l’API pour NoSQL principale, l’API pour Cassandra dans Azure Cosmos DB n’indexe pas tous les attributs par défaut. Au lieu de cela, elle prend en charge l’indexation secondaire pour créer un index sur certains attributs, qui se comporte de la même façon qu’Apache Cassandra.

En général, il n’est pas recommandé d’exécuter des requêtes de filtre sur les colonnes qui ne sont pas partitionnées. Vous devez utiliser la syntaxe ALLOW FILTERING de manière explicite, ce qui aboutit à une opération qui peut ne pas s’exécuter correctement. Dans Azure Cosmos DB vous pouvez exécuter de telles requêtes sur des attributs de faible cardinalité, car elles effectuent une distribution ramifiée dans des partitions pour récupérer les résultats.

Il n’est pas recommandé de créer un index sur une colonne fréquemment mise à jour. Il est prudent de créer un index lorsque vous définissez la table. Cela garantit que les données et les index sont dans un état cohérent. Si vous créez un nouvel index sur les données existantes, vous ne pouvez actuellement pas suivre la modification de la progression de l’index pour la table. Si vous avez besoin de suivre la progression de cette opération, vous devez demander la modification de la progression via un ticket de support.

Notes

Les index secondaires peuvent uniquement être créés à l’aide des commandes CQL mentionnées dans cet article, contrairement aux utilitaires du fournisseur de ressources (modèles ARM, Azure CLI, PowerShell ou Terraform). Les index secondaires ne sont pas pris en charge sur les objets suivants :

  • types de données tels que des types de collections gelées, de décimaux et de variantes.
  • Colonnes statiques
  • Clés de clustering

Avertissement

Les clés de partition ne sont pas indexées par défaut dans l’API pour Cassandra. Si votre table est constituée d’une clé primaire composée et que vous filtrez sur la clé de partition et la clé de clustering, ou seulement sur la clé de partition, vous obtiendrez le comportement voulu. En revanche, si vous filtrez sur la clé de partition et sur d’autres champs non indexés à part la clé de clustering, cela se traduira par une distribution ramifiée de clé de partition, même si les autres champs non indexés ont un index secondaire. Si votre table comprend une clé primaire composée et que vous souhaitez filtrer sur l’élément de valeur de clé de partition de la clé primaire composée et sur un autre champ qui n’est pas la clé de partition ou la clé de clustering, veillez à ajouter explicitement un index secondaire au niveau de la clé de partition. Dans ce scénario, l’index devrait améliorer considérablement les performances des requêtes, même si les autres champs de clé de non-partition et de non-clustering n’ont pas d’index. Pour plus d’informations, consultez notre article sur le partitionnement.

Exemple d’indexation

Commencez par créer un exemple d’espace de clés et une table en exécutant les commandes suivantes à l’invite de l’interpréteur de commandes CQL :

CREATE KEYSPACE sampleks WITH REPLICATION = {'class' : 'SimpleStrategy'};
CREATE TABLE sampleks.t1(user_id int PRIMARY KEY, lastname text) WITH cosmosdb_provisioned_throughput=400;

Ensuite, insérez les exemples de données utilisateur avec les commandes suivantes :

insert into sampleks.t1(user_id,lastname) values (1, 'nishu');
insert into sampleks.t1(user_id,lastname) values (2, 'vinod');
insert into sampleks.t1(user_id,lastname) values (3, 'bat');
insert into sampleks.t1(user_id,lastname) values (5, 'vivek');
insert into sampleks.t1(user_id,lastname) values (6, 'siddhesh');
insert into sampleks.t1(user_id,lastname) values (7, 'akash');
insert into sampleks.t1(user_id,lastname) values (8, 'Theo');
insert into sampleks.t1(user_id,lastname) values (9, 'jagan');

Si vous essayez d’exécuter l’instruction suivante, vous allez rencontrer une erreur vous demandant d’utiliser ALLOW FILTERING :

select user_id, lastname from sampleks.t1 where lastname='nishu';

Même si l’API pour Cassandra prend en charge la syntaxe ALLOW FILTERING, comme mentionné dans la section précédente, elle n’est pas recommandée. Au lieu de cela, vous devez créer un index comme indiqué dans l’exemple suivant :

CREATE INDEX ON sampleks.t1 (lastname);

Après avoir créé un index sur le champ « lastname », vous pouvez exécuter la requête précédente avec succès. Avec l’API pour Cassandra dans Azure Cosmos DB, vous n’avez pas à fournir de nom d’index. Un index par défaut avec le format tablename_columnname_idx est utilisé. Par exemple, t1_lastname_idx est le nom d’index pour le tableau précédent.

Suppression de l’index

Pour supprimer l’index, vous devez connaître son nom. Exécutez la commande desc schema pour afficher la description de votre table. La sortie de cette commande comprend le nom de l’index au format CREATE INDEX tablename_columnname_idx ON keyspacename.tablename(columnname). Vous pouvez ensuite utiliser le nom de l’index pour supprimer celui-ci, comme dans l’exemple suivant :

drop index sampleks.t1_lastname_idx;

Étapes suivantes