ElasticSearch o Couchbase o qualcos'altro

Question

Sfondo: Ho un enorme flusso di dati - ottenere fino a 1000000 record all'ora, ttl è di 3 ore ... Ogni "documento" contiene circa 20 proprietà, ho bisogno di cercare fino a 15 proprietà contemporaneamente utilizzando il confronto "==", "IN" e "BETWEEN".

Poiché non ci sono per lo più proprietà non ricercabili, non vi è motivo di archiviare il documento due volte (nell'indice Couchbase AND in ElasticSearch) quindi penso che sia una buona idea archiviarlo solo in ElasticSearch. Ho ragione?

O forse qualcuno può raccomandarmi un database migliore per tale compito? Ho bisogno di un facile scala orizzontale in futuro (sharding usanza di MySQL non è un'opzione) ... Questi dati sono una sorta di cache in modo eventuale consistenza e la scarsa durata è OK ...

Secondo teorema cap I Ho bisogno principalmente di A e P ...

Answer 1

Per quanto riguarda le prestazioni, purché si utilizzi un hardware di dimensioni appropriate, non si dovrebbero avere problemi nell'indicizzazione di documenti 1 M all'ora. Ho gestito Elasticsearch ben oltre questo senza problemi. C'è un interessante resoconto dettagliato qui che si possono trovare utili riguardanti il ​​benchmarking e il dimensionamento di un grande cluster elasticsearch:

ElasticSearch setup for a large cluster with heavy aggregations

Per un sistema di caching effimera con un TTL di sole 3 ore sono d'accordo che sarebbe stato uno spreco di memorizzare i dati in più di un repository. È possibile memorizzare i dati in Couchbase e replicarli in Elasticsearch in tempo reale o quasi in tempo reale, ma perché preoccuparsi di ciò? Non è certo quale beneficio otterresti dall'avere i dati in entrambi i posti.

Per problemi di prestazioni relativi al tuo caso d'uso specifico, suggerisco caldamente il benchmarking. Uno dei punti di forza di Elasticsearch (e anche di Solr) che ho trovato è la loro (a me) prestazione sorprendentemente forte durante la ricerca su più campi non di testo. Si tende a pensare a ES per scopi di ricerca testuale (dove eccellono) ma è anche un buon database per scopi generali. Ho scoperto che, in particolare, offre ottime prestazioni durante la ricerca su più parametri rispetto ad altre soluzioni NoSQL.

Personalmente, quando eseguo il benchmarking di ES in questo caso di utilizzo, guarderei un certo numero di opzioni di indicizzazione differenti.ES supporta TTL per i documenti di spurgo in modo automatico la cache è facile:

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-ttl-field.html

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html

Tuttavia si consiglia di giocare con avere indici diversi per ogni ogni ora - una cosa su ES (a causa di è l'uso di Lucene sotto per l'indicizzazione e la memorizzazione dei file) è che elimina il lavoro in modo diverso rispetto alla maggior parte dei database. I documenti sono contrassegnati come cancellati ma non rimossi, quindi periodicamente i file sottostanti (chiamati segmenti) verranno uniti, momento in cui verranno creati nuovi segmenti senza i documenti eliminati. Ciò può causare una discreta quantità di attività del disco per i casi di utilizzo pesante di eliminazione di volumi elevati in un singolo indice. Il modo per aggirare questo è creare un nuovo indice per ogni ora e quindi eliminare l'indice nella sua interezza dopo che i dati in esso sono più vecchi di 3 ore.

È possibile trovare questa discussione precedente circa TTL vs indici serie temporali in elasticsearch utile: Performance issues using Elasticsearch as a time window storage

Infine, per quanto riguarda facile scalabilità orizzontale elasticsearch è piuttosto buona qui - si aggiunge un nuovo nodo con il nome del cluster corretto e ES si occupa di tutto il resto, migrando automaticamente i frammenti al nuovo nodo. Nel tuo caso d'uso, potresti voler giocare con il fattore di replicazione, in quanto più repliche su più nodi sono il modo semplice per aumentare le prestazioni della query.

Answer 2

Per il caso d'uso di una cache (sistema cache-like), penso che Elasticsearch ti darà solo problemi in futuro. Suppongo che tu non abbia bisogno di indicizzazione perché non stai guardando le funzioni di ricerca.

Non ho usato Couchbase ma ne ho sentito parlare bene. Ho sentito casi d'uso come usare Couchbase per altri tipi di scopi di filtraggio e Elasticsearch per scopi di ricerca più (e cose che Couchbase non può fare).

Per la scalabilità, per quanto posso dire entrambi sembrano simili da un punto di vista di altissimo livello. Entrambi supportano la condivisione e la replica semplificate con il riequilibrio di frammenti e la promozione della replica secondaria su primaria quando un nodo nel cluster diminuisce. Le specifiche possono essere diverse.

Ma in tutta onestà, dovrai provarlo tu stesso e testare la produzione come il traffico. Ho lavorato con Elasticsearch e so che non puoi sempre dire se è la scelta giusta per il tuo caso d'uso, perché il modo in cui si comporta per un'applicazione in produzione può essere diverso per come si comporta per un altro in termini di prestazioni.

Ma penso che tu sia sulla buona strada.