Elasticsearch vs Cassandra vs Elasticsearch con Cassandra

Sto imparando NoSQL e sto esaminando diverse opzioni per uno dei requisiti del mio cliente. Ho esaminato varie risorse prima di porre questa domanda (una persona con poca conoscenza di NoSQL)

• Devo memorizzare i dati a una velocità maggiore e leggere i dati.
• Completamente a prova di errore e facilmente scalabile.
• In grado di cercare nei dati per Analytics.

Ho finito con un breve elenco di: Cassandra and Elasticsearch

Quello che capisco è che Cassandra è una soluzione di archiviazione NoSQL perfetta per me, poiché posso scrivere e leggere dati utilizzando gli indici. Dove fallisce o potrebbe fallire è su Analytics. In futuro, se voglio ottenere dati da from_date to to_dateo più modi per ottenere dati per analisi, se non progetto correttamente il modello di dati o se mantengo una visione a lungo termine, il che potrebbe essere piuttosto difficile in un mondo in continua evoluzione.

Mentre Elastic Searchè il migliore per l'indicizzazione (supportato da Lucene), e può cercare i dati in modo casuale lanciando del testo casuale. Ma funziona allo stesso modo anche se voglio recuperare i dati from_date to to_date(mi aspetto che potrebbe essere). Ma la vera domanda è: si tratta di un motore di ricerca o di un perfetto archivio dati NoSQL come Cassandra? Se sì, perché abbiamo ancora bisogno di Cassandra?

Se entrambi sono in un mondo diverso, spiegalo! Come li combiniamo per ottenere una soluzione più efficace?

Una delle nostre applicazioni utilizza i dati archiviati sia in Cassandra che in ElasticSearch. Usiamo Cassandra per accedere a tali record ogni volta che possiamo e duplicare i dati in tabelle di query progettate per aderire a specifiche richieste lato applicazione. Per una ricerca più liberale rispetto a quella consentita dalle nostre tabelle di query, ElasticSearch esegue bene questa funzionalità.

Abbiamo posto la stessa domanda (a noi stessi) ... "Perché non otteniamo tutto da ElastsicSearch?"

La risposta è che ElasticSearch è stato progettato per essere un motore di ricerca e non un archivio dati persistente. A volte ElasticSearch perde le scritture. Le modifiche allo schema sono difficili da fare in ElasticSearch senza soffiare via tutto e ricaricare. A tale scopo, ho scritto lavori progettati per mantenere ElasticSearch sincronizzato con il nostro cluster Cassandra. C'è stata anche una discussione abbastanza recente su Quora su questo argomento , che ha prodotto punti simili.

Detto questo, ElasticSearch funziona alla grande come motore di ricerca. E Cassandra funziona alla grande come datastore scalabile e ad alte prestazioni. Ma l' interrogazione dei dati è diversa dalla ricerca dei dati. A volte abbiamo bisogno dell'uno o dell'altro e una combinazione dei due funziona bene per la nostra applicazione. Potrebbe (o potrebbe non funzionare) bene per il tuo.

Per quanto riguarda l'analisi, ho avuto un certo successo nell'utilizzo del connettore Cassandra Spark, per servire query OLAP più complesse. Spero che aiuti.

Modifica 20200421

Ho scritto una risposta più recente a una domanda simile:

ElasticSearch contro ElasticSearch + Cassandra

Cassandra + Lucene è un'ottima opzione. Esistono diverse iniziative per questo problema, ad esempio:

• Indice Cassandra Lucene di Stratio - Derivato da Stratio Cassandra, è un plugin per Apache Cassandra che estende la sua funzionalità di indice. ( https://github.com/Stratio/cassandra-lucene-index )
• Stratio Cassandra, è un'integrazione nativa con Apache Lucene, è molto interessante. ( https://github.com/Stratio/stratio-cassandra ) - QUESTO PROGETTO È STATO INTERROTTO A FAVORE DELL'indice Cassandra Lucene di Stratio
• Tuplejump Calliope, è come Stratio Cassandra, ma è meno attivo. ( https://github.com/tuplejump/stargate-core )
• Ricerca DSE di Datastax. Consente di utilizzare Cassandra con Apache Solr, ma è un'opzione proprietaria. ( Http://www.datastax.com/what-we-offer/products-services/datastax-enterprise )

Dopo aver lavorato io stesso su questo problema, mi sono reso conto che i database NoSQL come casandra sono buoni quando vuoi assicurarti di preservare il tuo schema di dati con operazioni di scrittura affidabili e non vuoi sfruttare le operazioni di indicizzazione offerte da elasticsearch. Nel caso in cui desideri preservare alcuni dati degli indici, elasticsearch è utile nel caso in cui ti fidi del tuo schema e farai solo molte più letture che scritture.

Il mio caso era l'analisi dei dati. Quindi ho conservato molti dei miei Latice nella ricerca elastica poiché in seguito volevo attraversare molto i dati per vedere quale dovrebbe essere il mio prossimo passo. Avrei usato casandra se avessi voluto avere molti cambiamenti nello schema dei dati nelle mie linee guida analitiche.

Inoltre ci sono molti strumenti di rappresentazione carini come kibana che puoi usare per presentare i tuoi dati con una buona grafica. Forse sono pigro ma sono molto belli e mi hanno aiutato.

L'archiviazione dei dati in una combinazione di Cassandra ed ElasticSearch offre la maggior parte delle funzionalità. Ti consente di cercare tabelle di valori-chiave e di cercare dati negli indici.

La combinazione ti offre molta flessibilità, ideale per la tua applicazione.

Elassandra è la soluzione combinata di Cassandra + ricerca elastica, utilizza la ricerca elastica per indicizzare i dati e Cassandra come archivio dati, non sono sicuro delle prestazioni ma, come da questo articolo , le sue prestazioni sono buone.
Se la tua applicazione necessita di funzionalità di ricerca, Elassandra è la migliore opzione open source. La ricerca DSE è disponibile ma è costosa.

Avevamo sviluppato un'applicazione in cui abbiamo utilizzato Elasticsearch e Cassandra. Dati simili sono stati archiviati in Cassandra e indicizzati in Elasticsearch.

L'interfaccia utente della nostra applicazione aveva funzionalità come ricerche, aggregazioni, esportazione di dati, ecc. I microservizi di back-end ricevevano continuamente enormi dati (su argomenti Kafka) e li memorizzavano in Cassandra. Una volta che i dati sono stati archiviati in Cassandra, i servizi si assicurerebbero che i dati siano indicizzati in Elasticsearch.

Cassandra ha agito come "Fonte della verità" per Elasticsearch. Nei casi in cui fosse richiesta la reindicizzazione dell'indice ES, abbiamo interrogato Cassandra e reindicizzato i dati in ES.

Questa soluzione ci ha aiutato, poiché era molto facile da scalare e le ricerche e le aggregazioni erano molto più veloci.

• Poiché elasticsearch è basato sull'indice Lucene e se si desidera archiviare l'indicizzazione in elasticsearch, offre prestazioni migliori rispetto all'indicizzazione in Cassandra stessa per il recupero dei dati.
• Se i tuoi requisiti non sono correlati al recupero in tempo reale, puoi utilizzare elasticsearch anche come database NoSQL, ci sono pensieri che ElasticSearch perde le scritture e le modifiche allo schema sono difficili, ma se il tuo volume di dati non è troppo grande. Puoi facilmente ottenere elasticsearch come motore di ricerca con la migliore indicizzazione insieme a elasticsearch come database NoSQL. Esistono diversi modi per prevenirlo. Ho lavorato sulle modifiche allo schema in elasticsearch, se la struttura dei dati è coerente, creerà problemi.
• Essere un sostenitore di ElasticSearch o SOlr. Ho lavorato su entrambi i motori di ricerca e ho riscontrato che entrambi i motori di ricerca possono essere utilizzati fluentemente se configurati correttamente.
• Unico svantaggio che posso pensarci, se stai mirando al risultato in tempo reale e non puoi comprosie millisecondi di ritardo nella tua risposta. Allora è meglio prendere l'aiuto di altri database NoSQL come cassandra o couchbase.
• Cassandra con solr, funziona meglio di Cassandra con elasticSearch.

Cassandra è bravissima a recuperare i dati tramite ID . Non so molto sulla performance dell'indice secondario, ma dubito che sia veloce quanto Elasticsearch. Certamente Elasticsearch vince quando si tratta di funzionalità di ricerca del testo completo ( analisi del testo , punteggio di pertinenza , ecc.).

Cassandra vince anche per le prestazioni di aggiornamento . Elasticsearch supporta gli aggiornamenti, ma un aggiornamento è in realtà una reindicizzazione + eliminazione graduale in un'operazione atomica.

Cassandra ha un modello di replica molto carino (se devi essere extra-fail-safe). Anche Elasticsearch va bene, non sono nel campo che dice che ES è particolarmente inaffidabile (a volte ha problemi, come tutti i software).

Elasticsearch dispone anche di aggregazioni per analisi in tempo reale. E poiché le ricerche sono così veloci, anche le analisi su un sottoinsieme di dati saranno veloci .

Se le tue esigenze sono soddisfatte abbastanza bene da uno di loro (come qui sembra che ES funzionerebbe bene), ne userei solo uno. Se hai requisiti da entrambi i mondi, puoi:

• usane uno e aggira i lati negativi. Ad esempio, potresti essere in grado di gestire molti aggiornamenti con Elasticsearch, ma con più frammenti e più hardware
• usali entrambi e assicurati che siano sincronizzati