select * from update_audit where scopeid=35 and formid=78005 and record_link_id=9897;Come la query di cui sopra funzionerà internamente in cassandra?
In sostanza, tutti i dati per la partizione scopeid=35e formid=78005verranno restituiti e quindi filtrati dall’indice record_link_id. Cercherà la vocerecord_link_id per9897 e tenterà di abbinare le voci che corrispondono alle righe restituite dovescopeid=35 eformid=78005. Verrà restituita l’intersezione delle righe per le chiavi di partizione e le chiavi di indice.
In che modo l’indice high-cardinality column (record_link_id)influirà sulle prestazioni della query per la query precedente?
Gli indici di cardinalità alta creano essenzialmente una riga per (quasi) ogni voce nella tabella principale. Le prestazioni sono interessate, poiché Cassandra è progettato per eseguire letture sequenziali per i risultati delle query. Una query indice costringe essenzialmente Cassandra a eseguire letture casuali. Con l’aumentare della cardinalità del valore indicizzato, aumenta anche il tempo necessario per trovare il valore interrogato.
Cassandra toccherà tutti i nodi per la query di cui sopra? Perché?
No. Dovrebbe toccare solo un nodo responsabile della partizionescopeid=35 eformid=78005. Anche gli indici sono memorizzati localmente, contengono solo voci valide per il nodo locale.
la creazione dell’indice su colonne ad alta cardinalità sarà il modello di dati più veloce e migliore
Il problema qui è che l’approccio non scala e sarà lento se update_audit è un set di dati di grandi dimensioni. MVP Richard Low ha un grande articolo sugli indici secondari(il punto debole per l’indicizzazione secondaria di Cassandra), e in particolare su questo punto:
Se la tabella fosse significativamente più grande della memoria, una query sarebbe molto lenta anche per restituire solo poche migliaia di risultati. Restituire potenzialmente milioni di utenti sarebbe disastroso anche se sembrerebbe essere una query efficiente.
In pratica, questo significa che l’indicizzazione è più utile per restituire decine, forse centinaia di risultati. Tenetelo a mente quando si considera l’utilizzo di un indice secondario.
Ora, il tuo approccio di prima limitazione da una partizione specifica aiuterà (poiché la tua partizione dovrebbe certamente adattarsi alla memoria). Ma sento che la scelta migliore qui sarebbe quella di rendere record_link_id una chiave di clustering, invece di fare affidamento su un indice secondario.
Modifica
In che modo avere un indice su un indice di cardinalità basso quando ci sono milioni di utenti scala anche quando forniamo la chiave primaria
Dipenderà da quanto sono larghe le tue righe. La cosa complicata degli indici di cardinalità estremamente bassi è che la % delle righe restituite è solitamente maggiore. Ad esempio, si consideri una tabella users a riga larga. Si limita la chiave di partizione nella query, ma ci sono ancora 10.000 righe restituite. Se il tuo indice è su qualcosa come gender, la tua query dovrà filtrare circa la metà di quelle righe, il che non funzionerà bene.
Gli indici secondari tendono a funzionare meglio (per mancanza di una descrizione migliore) sulla cardinalità “middle of the road”. Utilizzando l’esempio precedente di un ampio riga users tabella, un indice country o state dovrebbe eseguire molto meglio di un indice gender (assumendo che la maggior parte di questi utenti non viviamo tutti nello stesso paese o stato).
Modifica 20180913
Per la tua risposta alla 1a domanda “Come funzionerà internamente la query di cui sopra in cassandra?”, sai qual è il comportamento quando si interroga con l’impaginazione?
Considera il seguente diagramma, tratto dalla documentazione del driver Java (v3.6):
Fondamentalmente, il paging causerà la rottura della query e il ritorno al cluster per la successiva iterazione dei risultati. Sarebbe meno probabile il timeout, ma le prestazioni tenderanno al ribasso, proporzionali alla dimensione del set di risultati totale e al numero di nodi nel cluster.
TL; DR; Più i risultati richiesti si diffondono su più nodi, più tempo ci vorrà.
