Quanto è affidabile ElasticSearch come datastore principale contro fattori quali perdita di scrittura, disponibilità dei dati

Question

Sto lavorando a un progetto con l'esigenza di creare un dashboard generico in cui gli utenti possono eseguire diversi tipi di raggruppamento, filtraggio e drill down su campi diversi. Per questo stiamo cercando un negozio di ricerca che permetta di tagliare e tagliare i dati.

Ci sarebbero più fonti di dati e lo staremmo archiviando nel Search Store. Potrebbe esserci qualche precalcolo richiesto sui dati di origine che può essere eseguito da componenti intermedi.

Ho esaminato diversi blog per capire se ES può essere utilizzato in modo affidabile come archivio principale anche. Dipende principalmente dal caso d'uso che stiamo cercando. Alcune delle informazioni sul caso d'uso che abbiamo:

• Circa 300 milioni di record all'anno con 1-2 KB.
• Supponendo di archiviare dati di 1 anno, siamo oggi con 300 GB, ma il caso di utilizzo può arrivare a 400-500 GB, data la crescita dei dati.
• A partire da ora non è sicuro, come verranno inviati i dati, ma, grosso modo, può arrivare a ~ 2-3 milioni di record ogni 5 minuti.
• La richiesta di ricerca è bassa, ma richiede query complesse che possono cercare dati per le ultime 6 settimane a 6 mesi.
• il documento verrà indicizzato in quasi tutti i campi del documento.

Alcuni blog dicono che è abbastanza affidabile da utilizzare come archivio dati primario -

• http://chrisberkhout.com/blog/elasticsearch-as-a-primary-data-store/
• http://highscalability.com/blog/2014/1/6/how-hipchat-stores-and-indexes-billions-of-messages-using-el.html
• https://karussell.wordpress.com/2011/07/13/jetslide-uses-elasticsearch-as-database/

E alcuni blog dire che ES hanno alcune limitazioni -

• https://www.found.no/foundation/elasticsearch-as-nosql/
• https://www.found.no/foundation/crash-elasticsearch/
• http://www.quora.com/Why-should-I-NOT-use-ElasticSearch-as-my-primary-datastore

Qualcuno ha usato elastica ricerca come unica verità di dati senza avere una storage primario come PostgreSQL, DynamoDB o RDS? Ho osservato che ES ha determinati problemi come il cervello diviso e la corruzione dell'indice in cui può esserci un problema con la perdita di dati. Quindi, sto cercando di sapere se qualcuno ha usato ES e ha avuto problemi con i dati

Grazie.

Answer 1

Generalmente è una buona idea progettare soluzioni di archiviazione dati ridondanti. Ad esempio, potrebbe essere un approccio rapido e affidabile prima di tutto spingere tutto come dati flat in un archivio statico come s3, quindi estrarre i dati ES e indicizzare da lì. Se hai bisogno di maggiore flessibilità sfruttando un ORM, potresti avere uno strato RDS o Redshift in mezzo. In questo modo i dati possono sempre essere ricostruiti in ES.

Dipende dalle esigenze e dai requisiti in cui si imposta l'equilibrio tra ridondanza e flessibilità/prestazioni. Se sono coinvolti molti dati, è possibile memorizzare staticamente i dati grezzi e indicarne solo alcune parti tramite ES.

Amazon Lambda offre grandi caratteristiche:

Molti oggetti sviluppatori negozio in Amazon S3 durante l'utilizzo di Amazon DynamoDB per memorizzare e indicizzare i metadati oggetto e attivare la ricerca ad alta velocità. AWS Lambda rende semplice mantenere tutto sincronizzato eseguendo una funzione per aggiornare automaticamente l'indice in Amazon DynamoDB ogni ora aggiunta o aggiornata da Amazon S3.

Answer 2

Risposta breve: dipende dal caso d'uso, ma probabilmente non si desidera utilizzarlo come negozio principale.

Risposta più lunga: è necessario comprendere tutti i possibili problemi che possono verificarsi in termini di resilienza e perdita di dati. Elastic ha qualche great documentation of these issues che dovresti veramente capire prima di usarlo come archivio dati primario. Inoltre Aphyr's post on the topic è una buona risorsa.

Se comprendi i rischi che stai assumendo e ritieni che tali rischi siano accettabili (ad esempio perché la perdita di dati di piccole dimensioni non rappresenta un problema per l'applicazione), dovresti sentirti libero di provarlo.