Elasticsearch Best practice e aumento delle prestazioni

Elasticsearch Best practice e aumento delle prestazioni
In questo post, cercheremo di raccogliere le migliori pratiche e anche quali cose da evitare quando si lavora con ElasticSearch e alimenta i dati in esso. In questo modo, sapremo quali cose di cui abbiamo bisogno per fare attenzione prima ancora di iniziare a lavorare con questo eccellente motore di ricerca.

Elasticsearch Best Practices

Inizieremo a lavorare con le migliori pratiche da seguire con ElasticSearch e quali problemi può creare quando evitiamo questi punti. Iniziamo.

Definisci sempre le mappature ES

Una cosa che ES può sicuramente fare è lavorare senza mappature. Quindi, quando inizi a alimentare i dati JSON all'indice ES, iterirà sui campi dei dati e creerà una mappatura adeguata. Questo sembra diretto e facile poiché ES è selezionare il tipo di dati stesso. Sulla base dei tuoi dati, potresti aver bisogno di un campo per essere di tipo specifico.

Ad esempio, supponiamo di indicizzare il seguente documento:


"id": 1,
"Titolo": "Installa Elasticsearch su Ubuntu",
"link": "https: // linuxhint.com/install-elasticsarch-ubuntu/",
"Data": "2018-03-25"

In questo modo, Elasticsearch segnerà il campo "Data" come tipo "Data". Ma quando indicizzi il seguente documento:


"id": 1,
"Titolo": "ES Best Practices and Performance",
"data": "in sospeso"

Questa volta, il tipo di campo è stato modificato e ES lancerà un errore e non consentirà di indicizzare il documento. Per rendere le cose facili, puoi indicizzare alcuni documenti, vedere quali campi sono indicizzati da ES e prendere la mappatura da questo URL:

Get/index_name/doc_type/_mapping

In questo modo, non dovrai costruire anche la mappatura completa.

Bandiere di produzione

Si chiama il nome del cluster predefinito che ES ES Elasticsearch. Quando hai molti nodi nel tuo cluster, è una buona idea mantenere le bandiere di denominazione il più coerenti possibile, come:

grappolo.Nome: app_es_production
nodo.Nome: app_es_node_001

A parte questo, anche le impostazioni di recupero per i nodi contano molto. Supponiamo che alcuni dei nodi in un riavvio del cluster a causa di un errore e alcuni nodi si riavviano un po 'dopo altri nodi. Per mantenere i dati coerenti tra tutti questi nodi, dovremo eseguire un programma di coerenza che manterrà tutti i cluster in uno stato coerente.

gateway.Recover_after_nodes: 10

È anche utile quando si dice in anticipo al cluster quanti nodi saranno presenti nel cluster e quanti tempi di recupero saranno necessari:

gateway.previsto_nodes: 20
gateway.Recover_after_time: 7m

Con la configurazione corretta, un recupero che avrebbe richiesto ore può richiedere un minuto e può risparmiare un sacco di soldi in qualsiasi azienda.

Provvedimento di capacità

È importante sapere quanto spazio prendono i tuoi dati e la velocità con cui scorre in ElasticSearch, perché deciderà la quantità di RAM di cui avrai bisogno su ciascuno dei nodi del cluster e anche su nodo principale.

Naturalmente, non ci sono linee guida specifiche per raggiungere i numeri necessari, ma possiamo fare alcuni passaggi che ci forniscono una buona idea. Uno dei passaggi sarà simulare il caso d'uso. Crea un cluster ES e alimentalo con quasi lo stesso tasso di dati che ci si aspetterebbe dalla configurazione della produzione. Il concetto di Inizia in grande e ridimensiona Può anche aiutarti a essere coerente su quanto spazio è necessario.

Modelli di grandi dimensioni

Quando si definiscono modelli di grandi dimensioni indicizzati, dovrai sempre affrontare problemi relativi alla sincronizzazione del modello attraverso i vari nodi del cluster. Si noti sempre che il modello dovrà essere definito nuovamente ogni volta che si verifica una modifica del modello di dati. È un'idea molto migliore Mantieni i modelli come dinamici. Modelli dinamici aggiornano automaticamente i mapping di campo in base alle mappature che abbiamo definito in precedenza e ai nuovi campi. Si noti che non vi è alcun sostituto per mantenere i modelli il più piccoli possibile.

2using mlockall sui server Ubuntu

Linux utilizza il processo di scambio quando ha bisogno di memoria per nuove pagine. Lo scambio di le cose rallentate poiché i dischi sono più lenti della memoria. IL mlockall Proprietà nella configurazione ES dice ad ES di non scambiare le sue pagine dalla memoria anche se per ora non sono necessarie. Questa proprietà può essere impostata nel file YAML:

bootstrap.Mlockall: vero

In es v5.versioni x+, questa proprietà è cambiata in:

bootstrap.Memory_lock: vero

Se stai usando questa proprietà, assicurati di fornire a ES una memoria di heap abbastanza grande usando il -Dxmx opzione o Es_heap_size.

Ridurre al minimo gli aggiornamenti di mappatura

Le prestazioni di un cluster sono leggermente interessate ogni volta che si effettuano richieste di aggiornamento di mappatura sul cluster ES. Se non riesci a controllarlo e si desidera ancora effettuare aggiornamenti alle mappature, è possibile utilizzare una proprietà nel file di configurazione ES YAML:

indici.grappolo.send_refresh_mapping: false

Quando la richiesta di aggiornamento del modello è in coda in sospeso per il nodo principale e invia i dati con la vecchia mappatura ai nodi, deve anche inviare una richiesta di aggiornamento in seguito a tutti i nodi. Questo può rallentare le cose. Quando impostiamo la proprietà sopra su False, questo ha senso principale che sia stato apportato un aggiornamento alla mappatura e non invierà la richiesta di aggiornamento ai nodi. Nota che questo è utile solo se apporti regolarmente molte modifiche alle mappature.

Pool thread ottimizzato

I nodi ES hanno molti pool di thread per migliorare il modo in cui i thread sono gestiti all'interno di un nodo. Ma ci sono limitazioni su quanti dati può occuparsi di ogni thread. Per tenere traccia di questo valore, possiamo usare una proprietà ES:

Threadpool.massa.queue_size: 2000

Ciò informa il numero di richieste in un frammento che può essere messo in coda per l'esecuzione nel nodo quando non è disponibile alcun thread per elaborare la richiesta. Se il numero di compiti aumenta di questo valore, otterrai un RemoteTransportException. Maggiore è questo valore, maggiore sarà la quantità di heap-spazio sulla macchina del nodo e più JVM heap verrà consumato. Inoltre, dovresti mantenere il tuo codice pronto nel caso in cui questa eccezione venga lanciata.

Conclusione

In questa lezione, abbiamo esaminato come possiamo migliorare le prestazioni di ElasticSearch evitando errori comuni e non così comuni che le persone fanno. Leggi altri articoli ElasticSearch su Linuxhint.