Posted by Ron Bodkin

Ed Anuff di usergrid presentati su tecniche di indicizzazione a Cassandra SF 2011 . Mentre Cassandra 0,7 e poi sono dotati di indici secondari, Anuff ha detto che non funzionano bene per i valori di cardinalità elevata, richiedono almeno un confronto di uguaglianza e di restituire i risultati indifferenziati. Anuff presentati i modelli per l'indicizzazione alternative tra cui file larghe e tabelle che utilizzano 0,81 Cassandra 's nuovi operatori di confronto composito per superare queste limitazioni, come pure in guardia contro l'uso di super-colonne.

Anuff ha detto che in Cassandra è un anti-modello di iterare chiavi per trovare record, invece si dovrebbe usare indici alternativi. Ha elencato i seguenti esempi di indici alternativi:

Nativo indici secondari
File larghe utilizzato per la ricerca e il raggruppamento
Personalizzati indici secondari

Super-Colonne

Anuff ha detto che nelle prime versioni di Cassandra, super-colonne sono state in genere utilizzato per l'indicizzazione alternativo, ma dice di "usare con cautela", notando che molti progetti si sono allontanati forma super-colonne a causa di problemi di prestazioni e di temi quali l'ordinamento non subcolumn e non essere in grado di nidificare doppiamente super-colonne. Egli ha osservato che le famiglie colonna Cassandra hanno di ordinamento e di confronto perché sono stati usati come un modo per implementare l'indicizzazione secondario.

Nativo indici secondari

Anuff spiegato che nativo indici secondari sono implementate con l'indice come una famiglia separata colonna nascosta.Indice nodi le righe che negozio, e quando si esegue una query che viene inviato a tutti i nodi, distribuendo il lavoro. Ha detto che Cassandra 0.8.1 utilizza gli indici per le operazioni di uguaglianza e che le operazioni di gamma vengono eseguite in memoria dal nodo coordinatore. Queste caratteristiche ne limitano l'applicazione, anche limitando il loro utilizzo ai tipi di dati che Cassandra capisce nativamente.

Righe ampia

Anuff ha detto che i nuovi arrivati a Cassandra chiedo spesso perché avrebbe bisogno di fila fino a 2 miliardi colonne. Egli ha sostenuto che le colonne sono alla base di indicizzazione, organizzazione e relativi elementi di Cassandra, e che "se il vostro modello di dati non contiene righe con oltre un centinaio di colonne, o siete facendo qualcosa di sbagliato o non si dovrebbe usare Cassandra. " File larghe possono essere usati per modellare le collezioni abbastanza grande, come la registrazione di una tabella di reparti in una società in questo modo:

dipartimenti = {

"Ingegneria": {"137acd": null, "e245116": null, ... }, "Vendite": {"334762": null, "17a632": null, ... }, ... }

Anuff notare questi vantaggi ad usare file larghe:

operazioni di colonna sono veloci
fette colonna può essere recuperato gamma
risultati sono sempre ordinati
se il vostro obiettivo chiave è un tempo a base di UUID si ottiene sia il raggruppamento e l'ordinamento per data e ora

Colonne composito

Tuttavia, l'approccio fila ampio funziona solo per mantenere le chiavi primarie, piuttosto che fornire un meccanismo di ricerca. In generale, ha detto che Anuff file larghe sono limitati a usare per mappature 1:1 (cioè, in cui ogni valore appare solo una volta di fila). Ad esempio, consideriamo una famiglia colonna per i gruppi che è indicizzato le voci in base al cognome. Anuff raccomandata con chiavi composte, che hanno costruito a sostegno di Cassandra 0.8.1 attraverso due nuovi comparatori. CompositeType è un comparatore di base, con una famiglia colonna per indice in cui l'utente specifica i tipi specifici e per ciascuna tipologia. Il DynamicCompositeType comparatore dinamico supporta gli altri casi, in cui gli utenti desiderano utilizzare una sola famiglia colonna con molti diversi indici, con ogni riga potenzialmente in possesso di un indice differente con diversi ordinamenti di valori diversi. Anuff notato che il DynamicCompositeType viene utilizzato per generare indici nella realizzazione APP nel Hector progetto, che è uno dei client Java per Cassandra, e uno che contribuisce alla Anuff.

Le chiavi composte possono assomigliare a questa:

User_Keys_By_Last_Name = {

"Ingegneria": {"anderson", 1: "ac1263", "Anderson", 2: "724f02", ... },

"Vendite": {"Adams", 1: "b32704", "Alden", 1: "1553bd", ... }, ... }

Anuff notato che è facile interrogare questi indici compositi, ma che il loro aggiornamento è difficile perché è necessario rimuovere i vecchi valori e inserire i nuovi valori. In generale, ha detto che la lettura prima di scrivere può essere un problema con Cassandra. Piuttosto che fare di chiusura (ad esempio, con Zookeeper ), Anuff presentato una tecnica che utilizza tre famiglie Colonna. Per esempio, in un tavolo con una famiglia Colonna utenti e una colonna di indici per famiglie, ci sarà un terzo Users_Index_Entries famiglia Colonna. Aggiornamenti prima di leggere i valori di indice precedente di questa famiglia colonna per evitare problemi di concorrenza e sia gli utenti IT e utilizzare le colonne timestamp per evitare la necessità di chiusura. Codice di esempio per come implementare questa tecnica può essere trovato in Anuff del progetto github CassandraIndexedCollections così come nelle diapositive di questa presentazione.