I dette innlegget vil vi prøve å samle beste praksis og også hvilke ting du skal unngå når vi jobber med Elasticsearch og fôrer data i det. På denne måten vil vi vite hva vi trenger å ta vare før vi selv begynner å jobbe med denne utmerkede søkemotoren.

Elasticsearch beste praksis

Vi begynner å jobbe med beste praksis å følge med Elasticsearch og hvilke problemer det kan skape når vi unngår disse punktene. La oss komme i gang.

Definer alltid ES -kartlegginger

En ting ES kan sikkert gjøre er å jobbe uten kartlegging. Så når du begynner å mate JSON -data til ES -indeksen din, vil den iterere over dataledene og lage en passende kartlegging. Dette virker direkte og enkelt ettersom ES velger selve datatypen. Basert på dataene dine, kan det hende du trenger et felt for å være av spesifikk datatype.

Anta for eksempel at du indekserer følgende dokument:

"id": 1,
"Tittel": "Installer Elasticsearch på Ubuntu",
"Link": "https: // linuxhint.com/install-elasticsearch-ubuntu/",
"Dato": "2018-03-25"

På denne måten vil Elasticsearch markere "dato" -feltet som "dato" -type. Men når du indekserer følgende dokument:

"id": 1,
"Tittel": "ES Best Practices and Performance",
"Dato": "Venter"

Denne gangen er typen av datofeltet endret og ES vil kaste en feil og vil ikke la dokumentet ditt indekseres. For å gjøre ting enkelt, kan du indeksere noen få dokumenter, se hvilke felt som er indeksert av ES og ta tak i kartleggingen fra denne url:

Get/index_name/doc_type/_mapping

På denne måten trenger du ikke å konstruere den komplette kartleggingen også.

Produksjonsflagg

Standard klyngenavn som ES starter kalles Elasticsearch. Når du har mange noder i klyngen din, er det en god idé å holde navnedommer så konsistente som mulig, som:

klynge.Navn: app_es_produksjon
Node.Navn: APP_ES_NODE_001

Bortsett fra dette, betyr også gjenopprettingsinnstillinger for noder. Anta at noen av nodene i en klynge -omstart på grunn av en feil, og noen noder starter litt etter andre noder. For å holde dataene konsistente mellom alle disse nodene, må vi kjøre konsistensprogram som vil holde alle klynger i en jevn tilstand.

inngangsport.gjenopprette_after_nodes: 10

Det er også nyttig når du forteller klyngen på forhånd hvor mange noder som vil være til stede i klyngen og hvor mye restitusjonstid disse trenger:

inngangsport.forventet_noder: 20
inngangsport.gjenopprette_after_time: 7m

Med riktig konfigurasjon kan en gjenoppretting som ville tatt timer ta så lite som et minutt og kan spare mye penger på ethvert selskap.

Kapasitetstilbud

Det er viktig å vite hvor mye plass dataene dine vil ta og hastigheten som de flyter inn i Elasticsearch, fordi det vil avgjøre mengden RAM du trenger på hver av noden til klyngen og masternoden også.

Det er selvfølgelig ingen spesifikke retningslinjer for å oppnå antall som trengs, men vi kan ta noen skritt som gir oss en god idé. Et av trinnene vil være å simulere Brukekassen. Lag en ES -klynge og mate den med nesten samme datahastighet som du kan forvente med produksjonsoppsettet. Konseptet av Start stort og skala ned kan også hjelpe deg å være konsekvent om hvor mye plass som trengs.

Store maler

Når du definerer indekserte store maler, vil du alltid møte problemer relatert til synkronisering av malen over de forskjellige nodene av klyngen. Legg alltid merke til at malen må defineres på nytt når en datamodellendring skjer. Det er en mye bedre ide å Hold malene som dynamiske. Dynamiske maler oppdaterer automatisk feltkartlegginger basert på kartleggingen vi definerte tidligere og de nye feltene. Merk at det ikke er noen erstatning for å holde malene så små som mulig.

2bruk Mlockall på Ubuntu -servere

Linux bruker bytteprosess når den trenger minne for nye sider. Bytting gjør ting tregt når disker er tregere enn minnet. De Mlockall Eiendom i ES -konfigurasjon ber ES om ikke å bytte sidene ut av minnet selv om de ikke er påkrevd for nå. Denne egenskapen kan settes i YAML -filen:

Støvelhempe.Mlockall: True

I ES V5.X+ versjoner, denne egenskapen har endret seg til:

Støvelhempe.Memory_lock: True

Hvis du bruker denne egenskapen, bare sørg for at du gir ES med store nok haug-memory ved å bruke -Dxmx alternativ eller ES_HEAP_SIZE.

Minimer kartleggingsoppdateringer

Ytelsen til en klynge påvirkes litt når du foretar kartleggingsforespørsler på ES -klyngen din. Hvis du ikke kan kontrollere dette og fremdeles vil gjøre oppdateringer til kartlegginger, kan du bruke en egenskap i ES YAML Config -fil:

indekser.klynge.send_refresh_mapping: falsk

Når modelloppdateringsforespørselen er i ventende kø for hovednoden og den sender data med den gamle kartleggingen til nodene, må den også sende en oppdateringsforespørsel senere til alle nodene. Dette kan gjøre ting tregt. Når vi setter egenskapen ovenfor til usant, gjør dette at Master er fornuftig at det er gjort en oppdatering til kartleggingen, og den vil ikke sende oppdateringsforespørselen til nodene. Merk at dette bare er nyttig hvis du gjør mange endringer i kartleggingen din regelmessig.

Optimalisert trådpool

ES -noder har mange trådbassenger for å forbedre hvordan tråder styres i en node. Men det er begrensninger i hvor mye data hver tråd kan ta vare på. For å holde oversikt over denne verdien, kan vi bruke en ES -egenskap:

Threadpool.bulk.Kø_størrelse: 2000

Dette informerer om antall forespørsler i en skjær som kan sto i kø for utførelse i noden når det ikke er noen tråd tilgjengelig for å behandle forespørselen. Hvis antall oppgaver går høyere enn denne verdien, vil du få en RemoteTransportException. Jo høyere denne verdien, jo høyere vil mengden av haug-rom være nødvendig på nodemaskinen din, og JVM-haugen vil også konsumeres. Du bør også holde koden din klar i tilfelle dette unntaket blir kastet.

Konklusjon

I denne leksjonen så vi på hvordan vi kan forbedre elasticsearch-ytelsen ved å unngå vanlige og ikke-så vanlige feil folk gjør. Les mer Elasticsearch -artikler om Linuxhint.