Ridimensionamento di ElasticSearch

Question

Sto cercando informazioni su come ElasticSearch si ridimensionerà con la quantità di dati nei suoi indici e sono sorpreso di quanto poco riesca a trovare su quell'argomento. Forse qualche esperienza dalla folla qui può aiutarmi.

Attualmente stiamo utilizzando CloudSearch per indicizzare ≈ 7 milioni di documenti; in CloudSearch questo risulta in 2 istanze di tipo m2.xlarge. Stiamo pensando di passare a ElasticSearch per ridurre il costo. Ma tutto ciò che trovo nel ridimensionamento di ElasticSearch è che funziona bene, può essere distribuito su più istanze, ecc.

Ma quale tipo di macchina (memoria, disco) avrei bisogno per questo tipo di dati?

Come cambierebbe se aumentassi la quantità di dati per il fattore 12 (≈ 80 milioni di documenti)?

Answer 1

In realtà ho recentemente passato dall'utilizzo di CloudSearch a un servizio ElasticSearch ospitato presso l'azienda per cui lavoro. La nostra applicazione specifica ha poco più di 100 milioni di documenti e cresce ogni giorno. Finora, la nostra esperienza con ElasticSearch è stata assolutamente meravigliosa. Cerca le medie delle prestazioni a ~ 250 ms, anche con tutti gli ordinamenti, i filtri e le sfaccettature. Anche i documenti di indicizzazione sono relativamente veloci, nonostante il carico di diversi MB che passiamo attraverso HTTP con l'API di massa ogni due ore. Anche i tassi di aggiornamento sembrano prossimi all'istante.

Per il nostro indice ~ 100M doc/12 GB, sono stati utilizzati 4 shard/2 repliche (si verificheranno fino a 3 repliche se le prestazioni si degradano) distribuite su 4 nodi. Prima di impostare l'indice, il nostro team ha trascorso un paio di giorni a ricercare la distribuzione/manutenzione del cluster ElasticSearch e ha scelto di utilizzare http://qbox.io per risparmiare tempo e denaro. Avevamo una paura paralizzante delle prestazioni e dei problemi di scala scegliendo di ospitare il nostro indice su un cluster dedicato come Qbox, ma finora l'esperienza è stata davvero fantastica.

Dal momento che il nostro indice è attivo su un cluster dedicato, non abbiamo accesso alle impostazioni di configurazione a livello di nodo di dadi e bulloni, quindi la mia esperienza tecnica con la distribuzione ES è ancora piuttosto limitata. Detto questo, non posso essere sicuro di quali siano esattamente le prestazioni necessarie per il rendimento che abbiamo riscontrato nel nostro indice. Tuttavia, so che il cluster di Qbox utilizza SSD ... in modo che possa avere un impatto significativo.

Punto nel caso, ElasticSearch è ridimensionato senza interruzioni. Consiglio vivamente lo switch (anche se è solo per risparmiare $$, CloudSearch è pazzesco costoso). Spero che questa informazione aiuti!

Answer 2

come Javanna said, dipende. Principalmente su: (1) tasso di indicizzazione; (2) dimensioni dei documenti; (3) requisiti di velocità e latenza per le ricerche; e (4) tipo di ricerche.

Considerato questo, il meglio che possiamo dare è dare esempi. Su our site (monitoraggio news) abbiamo:

1. Indice più di 100 documenti al minuto. Abbiamo attualmente circa 50 milioni di documenti. Ho anche sentito di indici ES con centinaia di milioni di documenti.
2. I documenti sono articoli di notizie con alcuni metadati, non brevi ma non così grandi.
3. La nostra latenza di ricerca varia tra ~ 50ms (per termini normali e rari) fino a 800ms per termini comuni (stopwords, li indicizziamo). Questa variazione è in gran parte dovuta al nostro punteggio personalizzato (grazie al supporto di Lucene/ES per la personalizzazione) e al fatto che il set di dati (elenchi invertiti) non si adatta interamente alla memoria (cache del sistema operativo). Quindi, quando raggiunge una lista invertita nella cache, è più veloce.
4. Facciamo query OR con un sacco di termini che sono uno dei più difficili. Facciamo anche sfaccettature su due campi a valore singolo. E avere alcuni esperimenti con sfaccettatura della data (per mostrare la velocità di pubblicazione nel tempo).

Facciamo tutto questo con le istanze di 4 EC2 m1.large. E ora stiamo pianificando di passare a ES, just released, 0.9 version per ottenere tutti i gadget e i miglioramenti delle prestazioni di Lucene 4.0.

Ora lasciando da parte gli esempi. ElasticSearch è abbastanza scalabile. È molto semplice creare un indice con N shards e repliche M e quindi creare macchine X con ES. Distribuirà tutti i frammenti e le repliche di conseguenza. Puoi cambiare il numero di repliche ogni volta che vuoi (per ogni indice).

Uno svantaggio è che non è possibile modificare il numero di frammenti dopo la creazione dell'indice. Ma si può ancora "overshard" in anticipo per lasciare spazio per il ridimensionamento quando necessario. O creare un nuovo indice con il giusto numero di frammenti e reindicizzare tutto (lo facciamo).

Infine, ElasticSearch (e anche Solr) utilizza, sotto il cofano, la libreria di ricerca Lucene, che è una libreria molto matura e ben nota.

Answer 3

CloudSearch recentemente abbandonato i prezzi e può ora essere un'alternativa più conveniente di mantenere il proprio Ricerca infrastrcuture su EC2 - http://aws.amazon.com/blogs/aws/cloudsearch-price-reduction-plus-features/