Indicizzazione secondaria in Azure Cosmos DB per Apache Cassandra

  • Articolo

SI APPLICA A: Cassandra

L'API per Cassandra in Azure Cosmos DB sfrutta l'infrastruttura di indicizzazione di base per mostrare la forza di indicizzazione intrinseca alla piattaforma. Tuttavia, a differenza dell'API principale per NoSQL, l'API per Cassandra in Azure Cosmos DB non indicizza tutti gli attributi per impostazione predefinita. Supporta invece l'indicizzazione secondaria per creare un indice su determinati attributi, che si comporta allo stesso modo di Apache Cassandra.

In generale, non si consiglia di eseguire query di filtro sulle colonne non partizionate. È necessario usare la sintassi ALLOW FILTERING in modo esplicito, che comporta un'operazione che potrebbe non funzionare correttamente. In Azure Cosmos DB è possibile eseguire queste query su attributi di cardinalità bassa perché si distribuiscono tra le partizioni per recuperare i risultati.

Non è consigliabile creare un indice in una colonna aggiornata di frequente. Si consiglia di creare un indice quando si definisce la tabella. Ciò garantisce che i dati e gli indici siano in uno stato coerente. Nel caso in cui si crei un nuovo indice sui dati esistenti, non è possibile attualmente tenere traccia della modifica dello stato dell'indice per la tabella. Se è necessario tenere traccia dello stato di avanzamento per questa operazione, è necessario richiedere la modifica dello stato tramite un ticket di supporto.

Nota

Gli indici secondari possono essere creati solo usando i comandi CQL indicati in questo articolo e non tramite le utility del fornitore di risorse (modelli ARM, interfaccia della riga di comando di Azure, PowerShell o Terraform). Gli indici secondari non sono supportati negli oggetti seguenti:

  • tipi di dati, ad esempio tipi di raccolta bloccata, decimali e variant.
  • Colonne statiche
  • Chiavi di clustering

Avviso

Le chiavi di partizione non vengono indicizzate per impostazione predefinita nell'API per Cassandra. Se si ha una chiave primaria composta nella tabella e si filtra in base alla chiave di partizione e alla chiave di clustering o semplicemente alla chiave di partizione, ciò darà il comportamento desiderato. Tuttavia, se si filtra in base alla chiave di partizione e a qualsiasi altro campo non indicizzato, a prescindere dalla chiave di clustering, verrà generato un fanout della chiave di partizione, anche se gli altri campi non indicizzati hanno un indice secondario. Se nella tabella è presente una chiave primaria composta e si vuole filtrare sia l'elemento del valore della chiave di partizione della chiave primaria composta, sia un altro campo che non è la chiave di partizione o la chiave di clustering, assicurarsi di aggiungere in modo esplicito un indice secondario nella chiave di partizione. L'indice in questo scenario dovrebbe migliorare significativamente le prestazioni delle query, anche se gli altri campi chiave non di partizione e chiave non di clustering non hanno indici. Per altre informazioni, vedere l'articolo sul partizionamento .

Esempio di indicizzazione

Creare prima di tutto un keyspace e una tabella di esempio eseguendo i comandi seguenti nel prompt della shell CQL:

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

Inserire quindi i dati utente di esempio con i comandi seguenti:

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');

Se si segue l'istruzione seguente, si verifica un errore che chiede di usare ALLOW FILTERING:

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

Anche se l'API per Cassandra supporta ALLOW FILTERING, come indicato nella sezione precedente, non si consiglia di usarlo. È invece necessario creare un indice come illustrato nell'esempio seguente:

CREATE INDEX ON sampleks.t1 (lastname);

Dopo aver creato un indice nel campo "lastname", è possibile eseguire correttamente la query precedente. Con l'API per Cassandra in Azure Cosmos DB non è necessario specificare un nome di indice. Viene utilizzato un indice predefinito con formato tablename_columnname_idx. Ad esempio, t1_lastname_idx è il nome dell'indice per la tabella precedente.

Eliminazione dell'indice

È necessario sapere qual è il nome dell'indice per eliminarlo. Eseguire il desc schema comando per ottenere la descrizione della tabella. L'output di questo comando include il nome dell'indice nel formato CREATE INDEX tablename_columnname_idx ON keyspacename.tablename(columnname). È quindi possibile usare il nome dell'indice per eliminare l'indice, come illustrato nell'esempio seguente:

drop index sampleks.t1_lastname_idx;

Passaggi successivi