Quando utilizzare Cassandra vs. Solr in DSE?

Question

Uso DSE per l'integrazione Cassandra/Solr in modo che i dati vengano archiviati in Cassandra e indicizzati in Solr. È molto naturale utilizzare Cassandra per gestire le operazioni CRUD e utilizzare Solr per la ricerca full text rispettivamente, e DSE può davvero semplificare la sincronizzazione dei dati tra Cassandra e Solr.

Quando si tratta di query, tuttavia, ci sono in realtà due modi per andare: Cassandra secondario/manuale configurato indice vs. Solr. Voglio sapere quando utilizzare il metodo e qual è la differenza di prestazioni in generale, specialmente in fase di configurazione del DSE.

Ecco un esempio di caso d'uso nel mio progetto. Ho una tabella Cassandra che memorizza alcuni dati di entità articolo. Oltre all'operazione CRUD di base, ho anche bisogno di recuperare gli oggetti in base all'uguaglianza in alcuni campi (ad esempio la categoria) e quindi ordinare secondo un certo ordine (nel mio caso, un campo like_count).

Posso pensare a tre diversi modi per gestire esso:

1. Declare 'indicizzati = true' nello schema Solr sia per categoria e settore like_count e query in Solr
2. Creare una tabella denormalizzato in Cassandra con chiave primaria (categoria, like_count, id)
3. Creare una tabella denormalizzato in Cassandra con chiave primaria (categoria, ordine, id) e utilizzare un componente esterno, come Spark/tempesta, per ordinare gli articoli da like_count

Il primo metodo sembra essere il più semplice da implementare e mantenere. Scrivo solo qualche codice di accesso Solr banale e il resto dei lavori pesanti viene gestito dalla ricerca Solr/DSE.

Il secondo metodo richiede denormalizzazione manuale su creazione e aggiornamento. Devo anche mantenere una tabella separata. Esiste anche un problema di rimozione delle pietre tombali dal momento che il like_count può essere aggiornato frequentemente. La parte buona è che la lettura potrebbe essere più veloce (se non ci sono lapidi eccessive).

Il terzo metodo può alleviare il problema delle pietre tombali al costo di un componente aggiuntivo per l'ordinamento.

Quale metodo ritiene sia l'opzione migliore? Qual è la differenza nelle prestazioni?

Answer 1

Cassandra indici secondari sono limitati casi di utilizzo:

1. Non più di un paio di colonne indicizzate.
2. Solo una singola colonna indicizzata in una query.
3. Troppo traffico tra nodi per i dati ad alta cardinalità (relativamente valori della colonna uniche)
4. Troppo traffico inter-nodo per dati a bassa cardinalità (alta percentuale di righe corrisponderà)
5. query devono essere conosciute in anticipo così il modello dei dati può essere ottimizzato attorno a loro.

A causa di queste limitazioni, è frequente che le app creino "tabelle indice" che sono indicizzate in base alla colonna desiderata. Ciò richiede che i dati vengano duplicati dalla tabella principale a ogni tabella dell'indice oppure sarà necessaria una query aggiuntiva per leggere la tabella dell'indice e quindi leggere la riga effettiva dalla tabella principale dopo aver letto la chiave principale dalla tabella dell'indice. Le query su più colonne dovranno essere indicizzate manualmente in anticipo, rendendo problematiche le query ad hoc. E ogni duplicato dovrà essere aggiornato manualmente dall'app in ogni tabella indice.

Diverso da quello ... funzioneranno correttamente nei casi in cui un numero "modesto" di righe verrà selezionato da un numero modesto di nodi e le query saranno ben specificate in anticipo e non ad hoc.

DSE/Solr è migliore per:

1. un moderato numero di colonne sono indicizzate.
2. Query complesse con un numero di colonne/campi di riferimento - Lucene corrisponde a tutti i campi specificati in una query in parallelo. Lucene indicizza i dati su ciascun nodo, quindi i nodi interrogano in parallelo.
3. Interrogazioni ad hoc in generale, in cui le query precise non sono note in anticipo.
4. Quesiti rich text quali ricerca parole chiave, carattere jolly, fuzzy/like, intervallo, disuguaglianza.

C'è un costo prestazioni e la capacità di utilizzare Solr l'indicizzazione, quindi si consiglia una prova di implementazione concetto di valutare quanto sono necessari ulteriori RAM, storage e nodi, che dipende dal numero di colonne di indice, il quantità di testo indicizzata e qualsiasi complessità di filtraggio del testo (ad esempio, n-grammi hanno bisogno di più.) Potrebbero andare dall'aumento del 25% per un numero relativamente piccolo di colonne indicizzate al 100% se tutte le colonne sono indicizzate. Inoltre, è necessario disporre di nodi sufficienti in modo che l'indice Solr per nodo vada nella RAM o principalmente nella RAM se si utilizza l'SSD. E i vnodes non sono attualmente raccomandati per i data center Solr.