Phenquestions
Elastiksøgning Bedste fremgangsmåder
Vi begynder at arbejde med bedste praksis for at følge med Elasticsearch og hvilke problemer det kan skabe, når vi undgår disse punkter. Lad os komme igang.
Definer altid ES Mappings
Én ting ES helt sikkert kan gøre er at arbejde uden kortlægninger. Så når du begynder at fodre JSON-data til dit ES-indeks, vil det gentage sig over datafelterne og oprette en passende kortlægning. Dette virker direkte og let, da ES vælger selve datatypen. Baseret på dine data har du muligvis brug for et felt for at være af specifik datatype.
Antag for eksempel, at du indekserer følgende dokument:
"id": 1,
"title": "Installer ElasticSearch på Ubuntu",
"link": "https: // linuxhint.com / install-elasticsearch-ubuntu / ",
"date": "2018-03-25"
På denne måde markerer Elasticsearch feltet "dato" som "dato". Men når du indekserer følgende dokument:
"id": 1,
"title": "ES bedste praksis og ydeevne",
"date": "Afventer"
Denne gang er datofeltets type blevet ændret, og ES kaster en fejl og tillader ikke, at dit dokument indekseres. For at gøre tingene lette kan du indeksere et par dokumenter, se hvilke felter der er indekseret af ES og få fat i kortlægningen fra denne URL:
GET / index_name / doc_type / _mappingPå denne måde behøver du ikke at konstruere den komplette kortlægning også.
Produktionsflag
Standardklyngenavnet, som ES starter, kaldes elastiksøgning. Når du har mange noder i din klynge, er det en god ide at holde navngivningsflagene så ensartede som muligt, som:
klynge.navn: app_es_productionknude.navn: app_es_node_001
Bortset fra dette betyder gendannelsesindstillinger for noder også meget. Antag, at nogle af knudepunkterne i en klynge genstart på grund af en fejl, og nogle noder genstarter lidt efter andre noder. For at holde dataene konsistente mellem alle disse noder skal vi køre konsistensprogram, der holder alle klynger i en konsistent tilstand.
gateway.recover_after_nodes: 10Det er også nyttigt, når du på forhånd fortæller klyngen, hvor mange noder der vil være til stede i klyngen, og hvor meget gendannelsestid disse har brug for:
gateway.forventede knudepunkter: 20gateway.gendanne_efter_tid: 7m
Med den korrekte konfiguration kan en genopretning, der ville have taget timer, tage så lidt som et minut og kan spare mange penge til ethvert firma.
Kapacitetsforsyning
Det er vigtigt at vide, hvor meget plads dine data tager og den hastighed, hvormed de strømmer ind i Elasticsearch, for det bestemmer også, hvor meget RAM du har brug for på hver af klyngens knudepunkter og masternoden.
Der er naturligvis ingen specifikke retningslinjer for at nå de nødvendige tal, men vi kan tage nogle skridt, der giver os en god idé. Et af trinene vil være at simulere brugssagen. Opret en ES-klynge, og fød den med næsten den samme datahastighed, som du ville forvente med din produktionsopsætning. Begrebet start stort og skaler ned kan også hjælpe dig med at være konsekvent med hensyn til, hvor meget plads der er brug for.
Store skabeloner
Når du definerer indekserede store skabeloner, vil du altid stå over for problemer relateret til synkronisering af skabelonen på tværs af dine forskellige noder i klyngen. Bemærk altid, at skabelonen skal omdefineres, hver gang der sker en ændring af datamodellen. Det er en meget bedre idé at holde skabelonerne så dynamiske. Dynamiske skabeloner opdaterer automatisk marktilknytninger baseret på de tilknytninger, vi definerede tidligere og de nye felter. Bemærk, at der ikke er nogen erstatning for at holde skabelonerne så små som muligt.
2 Brug af mlockall på Ubuntu-servere
Linux bruger swapping-processen, når det har brug for hukommelse til nye sider. Ombytning gør tingene langsomme, da diske er langsommere end hukommelsen. Det mlockall egenskab i ES-konfiguration beder ES om ikke at bytte sine sider ud af hukommelsen, selvom de ikke er nødvendige for nu. Denne egenskab kan indstilles i YAML-filen:
bootstrap.mlockall: sandtI ES v5.x + versioner, denne egenskab er ændret til:
bootstrap.memory_lock: sandtHvis du bruger denne egenskab, skal du bare sørge for at give ES stor nok hukommelseshukommelse ved hjælp af -DXmx valgmulighed eller ES_HEAP_SIZE.
Minimer kortopdateringer
En klynges ydeevne påvirkes lidt, når du foretager tilknytningsopdateringsanmodninger i din ES-klynge. Hvis du ikke kan kontrollere dette og stadig vil foretage opdateringer til tilknytninger, kan du bruge en egenskab i ES YAML-konfigurationsfilen:
indekser.klynge.send_refresh_mapping: falskNår modelopdateringsanmodningen er i ventende kø til masternoden, og den sender data med den gamle kortlægning til noderne, skal den også sende en opdateringsanmodning senere til alle noderne. Dette kan gøre tingene langsomme. Når vi indstiller ovenstående egenskab til falsk, giver det mest mening, at der er foretaget en opdatering af kortlægningen, og den sender ikke anmodningen om opdatering til noderne. Bemærk, at dette kun er nyttigt, hvis du regelmæssigt foretager en masse ændringer i dine tilknytninger.
Optimeret tråd-pool
ES-noder har mange trådpuljer for at forbedre, hvordan tråde styres inden for en node. Men der er begrænsninger for, hvor meget data hver tråd kan tage sig af. For at holde styr på denne værdi kan vi bruge en ES-egenskab:
threadpool.bulk.køstørrelse: 2000Dette informerer ES om antallet af anmodninger i en shard, som kan stå i kø til udførelse i noden, når der ikke er nogen tråd tilgængelig til behandling af anmodningen. Hvis antallet af opgaver går højere end denne værdi, får du en RemoteTransportException. Jo højere denne værdi er, jo højere er mængden af bunkerum på din nodemaskine, og JVM-bunken forbruges også. Du skal også holde din kode klar, hvis denne undtagelse smides.
Konklusion
I denne lektion så vi på, hvordan vi kan forbedre Elasticsearch-ydeevne ved at undgå almindelige og ikke så almindelige fejl, folk laver. Læs mere Elasticsearch-artikler om LinuxHint.
