Elasticsearch autofuldførelse Guide

Opster Team

sidste opdatering: Mar 2021

Opster Team

Marts 2021

ud over at læse denne vejledning anbefaler vi, at du kører Elasticsearch Health Check-up. Det vil opdage problemer og forbedre din Elasticsearch ydeevne ved at analysere dine shard størrelser, threadpools, hukommelse, snapshots, disk vandmærker og meget mere.Elasticsearch Check-Up er gratis og kræver ingen installation.

ud over at læse denne vejledning skal du køre Opsters Søgeloganalysator, hvis du vil forbedre din søgeydelse i Elasticsearch.

med Opster ‘ s analysator kan du nemt finde langsomme søgninger og forstå, hvad der førte til, at de tilføjede ekstra belastning til dit system. Du modtager tilpassede anbefalinger til, hvordan du reducerer søgeforsinkelse og forbedrer din søgeydelse. Værktøjet er gratis og tager kun 2 minutter at køre.

baggrund

i denne artikel vil vi dække, hvordan man undgår kritiske ydelsesfejl, hvorfor Elasticsearch-standardløsningen ikke skærer den, og vigtige implementeringsovervejelser.
alle moderne hjemmesider har autofuldførelse funktioner (Søg som du skriver) på deres søgefelt for at forbedre brugeroplevelsen (ingen ønsker at skrive hele søgetermer…). Det er bydende nødvendigt, at autofuldførelsen er hurtigere end standardsøgningen, da hele pointen med autofuldførelse er at begynde at vise resultaterne, mens brugeren skriver. Hvis latensen er høj, vil det føre til en subpar brugeroplevelse.

nedenfor er et eksempel på autofuldførelse af søgning på det berømte spørgsmål og svar-sted, kvora. Dette er et godt eksempel på autofuldførelse: når du søger efter elasticsearch auto, følgende indlæg begynder at blive vist i deres søgefelt.

 dette billede har en tom alt-attribut; dens filnavn er GtQyiRxpwyXg_NmYFLO5mSlG5Zwa-k6a-s2AIi-uP3EsEP8dRql8eR0CrfGZlN_PIcUMU9K-GDZ2WfEASrxgxGSXiE37pzwNNffIcjq-xlBA982DZe8TQJFzYaLl8WojdrdlVNjQ

Bemærk, at der i søgeresultaterne er spørgsmål vedrørende funktionerne auto-skalering, auto-tag og autofuldførelse i Elasticsearch. Brugere kan yderligere skrive et par flere tegn for at forfine søgeresultaterne.

forskellige tilgange til autofuldførelse i Elasticsearch / search, mens du skriver

der er flere måder at implementere autofuldførelsesfunktionen på, som stort set falder i fire hovedkategorier:

  1. Indekstid
  2. Forespørgselstid
  3. færdiggørelsesforslag
  4. Søg-som-du-Type database

1. Indekstid

nogle gange er kravene bare færdiggørelse af præfiks eller færdiggørelse i autofuldførelse. Det er ikke ualmindeligt at se autofuldførelsesimplementering ved hjælp af brugerdefinerede analysatorer, hvilket indebærer indeksering af tokens på en sådan måde, at den matcher brugerens søgeudtryk.
hvis vi fortsætter med vores eksempel, ser vi på dokumenter, der består af “elasticsearch autofuldførelse”, “elasticsearch auto-tag”, “elasticsearch auto skalering” og “elasticsearch automatisk”. Standardanalysatoren genererer ikke nogen delvise tokens til” autofuldførelse”,” Autoskalering “og” automatisk”, og søgning” auto ” ville ikke give nogen resultater.
for at overvinde ovenstående problem bruges edge ngram eller n-gram tokenisator til at indeksere tokens i Elasticsearch, som forklaret i den officielle ES doc og search time analysator for at få autofuldførelsesresultaterne.
ovenstående tilgang bruger Matchforespørgsler, som er hurtige, da de bruger en streng sammenligning (som bruger hashcode), og der er forholdsvis mindre nøjagtige tokens i indekset.

2. Forespørgselstid

autofuldførelse kan opnås ved at ændre matchforespørgsler til præfiksforespørgsler. Mens match forespørgsler arbejde på token (indekseret) til token (søgeforespørgsel tokens) match, præfiks forespørgsler (som deres navn antyder) matche alle tokens startende med Søg tokens, dermed antallet af dokumenter (resultater) matchede er høj.

som forklaret, præfiks forespørgsel er ikke en nøjagtig token match, snarere det er baseret på tegn kampe i strengen, som er meget dyrt og henter en masse dokumenter. Elasticsearch bruger internt en B + træ slags datastruktur til at gemme sine tokens. Det er nyttigt at forstå internalerne i datastrukturen, der bruges af inverterede indekser, og hvordan forskellige typer forespørgsler påvirker ydeevnen og resultaterne.

3. Færdiggørelse suggester

dette er nyttigt, hvis du giver forslag til søgeord som på e-handel og hotelsøgning hjemmesider. Søgefeltet tilbyder forespørgselsforslag i modsætning til de forslag, der vises i de faktiske søgeresultater, og efter at have valgt et af forslagene fra færdiggørelsesforslag, giver det søgeresultaterne.

som nævnt på det officielle ES doc er det stadig i udviklingsbrug og henter ikke søgeresultaterne baseret på søgeudtryk som forklaret i vores eksempel.

internt fungerer det ved at indeksere de tokens, som brugerne vil foreslå og ikke baseret på eksisterende dokumenter.

kodeprøver

1. Indeks tid

indeks definition:

{ "settings": { "analysis": { "filter": { "autocomplete_filter": { "type": "edge_ngram", "min_gram": 1, "max_gram": 10 } }, "analyzer": { "autocomplete": { "type": "custom", "tokenizer": "standard", "filter": } } } }, "mappings": { "properties": { "title": { "type": "text", "analyzer": "autocomplete", "search_analyzer": "standard" :-> note search_analyzer } } }}

søgeforespørgsel:

{ "query": { "match": { "movie_name": { "query": "avengers inf" } } }}

2. Forespørgselstid

Indeksdefinition:

{ "mappings": { "properties": { "movie_name": { "type": "text" } } }}

søgeforespørgsel:

{ "query": { "bool": { "should": } }}

4. Søg, mens du skriver

det er en nyligt frigivet datatype (udgivet i 7.2), der er beregnet til at lette autofuldførelsesforespørgsler uden forudgående kendskab til brugerdefineret analysatoropsætning. Elasticsearch gemmer internt de forskellige tokens (kant n-gram, helvedesild) af den samme tekst, og derfor kan bruges til både præfiks og infiks færdiggørelse. Det kan være praktisk, hvis ikke bekendt med de avancerede funktioner i Elasticsearch, hvilket er tilfældet med de andre tre tilgange. Der kræves ikke meget konfiguration for at få det til at fungere med enkle brugssager, og kodeprøver og flere detaljer er tilgængelige på officielle ES-dokumenter.

Ydelsesovervejelse

næsten alle ovenstående tilgange fungerer fint på mindre datasæt med lettere søgebelastninger, men når du har et massivt indeks, der får et stort antal auto foreslå forespørgsler, er SLA og ydeevne for ovenstående forespørgsler afgørende . Følgende kuglepunkter skal hjælpe dig med at vælge den tilgang, der passer bedst til dine behov:

  • Ngram eller edge Ngram tokens øger indeksstørrelsen betydeligt, hvilket giver grænserne for min og maks gram i henhold til anvendelse og kapacitet. Planlægning ville spare betydelige problemer i produktionen.
  • hvis du tillader tomme eller få tegnpræfiksforespørgsler, kan du hente alle dokumenter i et indeks og har potentialet til at nedbringe en hel klynge. Det er altid en bedre ide at gøre præfiks forespørgsel kun på nth sigt(på få felter) og begrænse minimumstegn i præfiks forespørgsler.
  • ES forudsat “Søg som du skriver” datatype tokeniserer input tekst i forskellige formater. Da det er en ES-leveret løsning, der ikke kan adressere alle brugssager, er det altid en bedre ide at kontrollere alle de hjørnesager, der kræves til din virksomheds brugssag. Desuden, som nævnt det tokeniserer felter i flere formater, som kan øge Elasticsearch indeks butik størrelse.
  • færdiggørelse foreslår separat indeksering af forslagene, og en del af det er stadig i udviklingstilstand og adresserer ikke brugssagen til at hente søgeresultaterne.
  • indekstidsmetoder er hurtige, da der er mindre overhead under forespørgselstid, men de involverer mere grunt arbejde, som omindeksering, kapacitetsplanlægning og øgede diskomkostninger. Forespørgselstid er let at implementere, men søgeforespørgsler er dyre. Dette er meget vigtigt at forstå, da brugerne for det meste har brug for at vælge en af dem, og at forstå denne afvejning kan hjælpe med mange problemer med fejlfinding af ydeevne.

diverse

i de fleste tilfælde leverede ES-løsninger til autofuldførelse enten ikke adresserer forretningsspecifikke krav eller har ydeevnepåvirkninger på store systemer, da disse ikke er løsninger, der passer til alle. Det meste af tiden skal brugerne tilpasse for at få den optimerede løsning (mere performant og fejltolerant), og det er ikke trivielt at håndtere Elasticsearch-ydelsesproblemer. Opster hjælper med at opdage dem tidligt og giver support og de nødvendige værktøjer til at fejle og forhindre dem effektivt.

for yderligere læsning bedes du gennemgå :

  1. Opster ‘ s guide om øget søgeforsinkelse for at få nogle indsigter og forbedre ydeevnen.
  2. Opster ‘ s guide til, hvordan du bruger Søg langsomt logs om, hvordan du hurtigt debug langsom søgning problemer

forbedre Elasticsearch ydeevne

Kør analysen

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.