Elastična pretraga u proizvodnji - Najbolje prakse primjene

Elasticsearch je visoko optimizirana tražilica za suvremenu analizu podataka.

Elasticsearch je nevjerojatan motor za pretraživanje i analitiku u stvarnom vremenu. Izgrađena je na Apache Lucene. Distribuira se, ODNOSNO, lako se koristi i vrlo je dostupno. Slučajevi korištenja elastičnog pretraživanja uključuju pokretanje pretraživanja, nadzor transakcija i otkrivanje pogrešaka, otkrivanje sadržaja, analizu dnevnika, nejasno pretraživanje, objedinjavanje podataka o događajima, vizualizaciju podataka. Elasticsearch i ostatak Elastic Stack-a pokazali su se izuzetno svestranima, a kao što možete vidjeti na gornjim primjerima upotrebe, postoji više načina za integriranje Elasticsearcha u ono što vaš proizvod danas nudi i dodavanje dodatnog uvida u njega.

Snažno ga koristimo za pretraživanje i analitiku na Botmetricu, indeksiramo oko milijardu dokumenata i koristimo vrlo složene agregacije za vizualizaciju podataka u stvarnom vremenu.

To je rečeno, pokretanje aplikacije u odnosu na pokretanje u proizvodnji i održavanje potpuno su različite. Ova čaura pokriva mnoge od tih faktora iz stvarnih životnih iskustava i osnovne su stavke koje biste trebali razmotriti za pokretanje elastičnog pretraživanja u proizvodnji.

Memorija:

Elasticsearch i Lucene su napisani na Javi, što znači da morate paziti na statistiku velikog prostora i JVM. Što je više hrpe dostupno Elasticsearchu, više memorije koju može koristiti za filtriranje i drugo predmemoriranje za povećanje performansi upita. Ali imajte na umu da previše hrpe može vas izložiti dugim pauzama prikupljanja smeća. Ne postavljajte Xmx iznad presjeka koji JVM koristi za komprimirane pokazivače objekta (komprimirani oops); točna vrijednost rezanja varira, ali iznosi blizu 32 GB.

Čest problem je konfiguriranje kopče koja je prevelika. Imate stroj od 64 GB - i hvala, želite Elasticsearchu dati svih 64 GB memorije. Više je bolje! Heap je definitivno važan za Elasticsearch. Mnoge podatkovne strukture koriste ga za brzi rad. Ali uz to rečeno, postoji još jedan glavni korisnik memorije koja je izuzeta: predmemorija OS datoteka.

Lucene je dizajniran tako da koristi temeljni OS za keširanje podataka u memoriji. Lucenski segmenti pohranjuju se u pojedinačne datoteke. Kako su segmenti nepromjenjivi, te se datoteke nikada ne mijenjaju. To ih čini vrlo predmemorirajućim predmemorijom, a temeljni OS rado će zadržati vruće segmente u sjećanju za brži pristup. Ovi segmenti uključuju i obrnuti indeks (za pretraživanje u cijelom tekstu) i doc vrijednosti (za združivanje). Lucenove izvedbe oslanjaju se na tu interakciju sa OS-om. Ali ako date svu dostupnu memoriju u hrpu Elasticsearch-a, neće preostati ništa više za predmemoriju datoteka OS. To može ozbiljno utjecati na performanse. Standardna preporuka je dati 50% raspoložive memorije u hrpu Elasticsearch, a ostalih 50% ostaviti slobodnima. Neće se iskoristiti; Lucene će rado konzumirati sve što je preostalo za predmemoriju datoteka. Elasticsearch hrpa može se konfigurirati na sljedeće načine,

izvoz ES_HEAP_SIZE = 10 g

ili

ES_JAVA_OPTS = "- Xms10g -Xmx10g" ./bin/elasticsearch

procesor:

Elasticsearch podržava združivanje i filtrirane upite. Za pokretanje složenih filtriranih upita, intenzivno indeksiranje, perkolacija i upiti prema indeksima potreban je težak CPU, tako da je odabir pravog ključan. Morate razumjeti specifikacije CPU-a i kako se oni ponašaju s Javom dok se upiti pokreću na JVM-u.

Svaki bazen pokreće niz niti koje se mogu konfigurirati i imaju red čekanja. Promjena nije preporučljiva osim ako nemate vrlo specifične zahtjeve jer Elasticsearch dodjeljuje jezgre dinamički.

Vrste bazena navoja:

Elasticsearch ima 3 vrste navoja bazena.

  1. Predmemorirano: Spremljeni spremljeni niz niti je neograničeni niz niti koji će roditi nit ako ima zahtjeva na čekanju. Taj se niz niti koristi za sprječavanje blokiranja ili odbijanja zahtjeva poslanih u ovaj bazen. Neiskorištene niti u ovom nizu niti završit će se nakon što istekne vrijeme zadržavanja (zadano je na pet minuta). Spremljeni spremljeni niz niti rezerviran je za generički niz niti.
  2. Fiksno: Spremnik fiksnih niti sadrži fiksnu veličinu niti za rukovanje zahtjevima s redom (neobavezno ograničen) za zahtjeve na čekanju koji nemaju niti za njihovo servisiranje. Parametar veličine kontrolira broj niti i podrazumijeva broj jezgara 5 puta.
  3. Skaliranje: Bazen za skaliranje niti sadrži dinamički broj niti. Taj je broj proporcionalan radnom opterećenju i varira između 1 i vrijednosti parametra veličine.

Elasticsearch dijeli upotrebu CPU-a u nizove različitih vrsta:

  • općenito: za standardne operacije kao što su otkrivanje i vrsta baze podataka niti se sprema u predmemoriju.
  • indeks: za indeksiranje / brisanje. Vrsta baze navoja je fiksna.
  • pretraživanje: za brojanje / pretraživačke operacije. Vrsta baze navoja je fiksna.
  • get: za dobivanje operacija. Vrsta baze navoja je fiksna.
  • skupno: za skupne operacije kao što su skupno indeksiranje. Vrsta baze navoja je fiksna. Najbolja konfiguracija skupnih dokumenata ovisi o konfiguraciji klastera, a to se može prepoznati isprobavanjem više vrijednosti.
  • perkola: za perkolaciju. Vrsta baze navoja je fiksna.
  • refresh: za operacije osvježavanja. Vrsta baze navoja je skaliranje.

Promjena određenog skupa niti može se postaviti postavljanjem njegovih parametara specifičnih za tip.

Pročitajte više https://www.elastic.co/guide/en/elasticsearch/reference/2.2/modules-threadpool.html#types

Veličina suknje:

Shard je jedinica na kojoj Elasticsearch distribuira podatke unutar klastera. Brzina kojom Elasticsearch može pomicati komadiće prilikom rebalansiranja podataka, npr. Nakon kvara ovisit će o veličini i broju komadića te mrežnoj i diskovnoj izvedbi.

U Elasticsearch-u se svaki upit izvršava u jednoj niti po dijelu. Međutim, više komada se može obraditi paralelno, kao i više upita i združivanja protiv istog dijela.

To znači da će minimalna kašnjenja upita, kada nije uključeno predmemoriranje, ovisiti o podacima, vrsti upita kao i veličini dijeljenja. Upiti puno malih komada ubrzat će obradu po djeliću, ali kako je potrebno još mnogo zadataka u redu i obrađivati ​​redoslijed, to neće nužno biti brže od upita manjeg broja većih komada. Imajući puno malih komada također može smanjiti propusnost upita ako postoji više istodobnih upita.

Svaki dijelić ima podatke koje treba čuvati u memoriji i koristi heap prostor. Ovo uključuje strukture podataka koje sadrže informacije na razini sjemena i također na razini segmenta kako bi se definiralo gdje se podaci nalaze na disku. Veličina ovih struktura podataka nije fiksna i razlikuje se ovisno o slučaju uporabe. Jedna važna karakteristika segmenta koji se odnosi na njega je da nije strogo proporcionalan veličini segmenta. To znači da veći segmenti imaju manje režijskih troškova po količini podataka u usporedbi s manjim segmentima. Razlika može biti znatna. Odabir pravog broja komadića je složen jer nikad ne znate koliko ćete dokumenata dobiti prije nego što započnete. Imati puno komada može biti dobro i grozno za grozd. Upravljanje indeksima i komadima može preopteretiti glavni čvor, što može postati ne reagiralo, što bi dovelo do neobičnog i gadnog ponašanja. Dodijelite glavnim čvorovima dovoljno resursa da se nose s veličinom klastera.

Loša stvar je što je broj komada nepromjenjiv i definira se kada kreirate indeks. Jednom kada se kreira indeks, jedini način za promjenu broja komada je brisanje indeksa, ponovno stvaranje i ponovno izrađivanje.

odgovor

Elasticsearch podržava replikaciju, podaci se repliciraju među čvorovima podataka tako da gubitak čvora ne bi doveo do gubitka podataka. Faktor replikacije prema zadanim postavkama je 1, ali ovisno o zahtjevima vašeg proizvoda može se povećati. Što će više vaših replika biti otporniji na katastrofe. Još jedna prednost postojanja više replika je ta što svaki čvor sadrži dio replike, što poboljšava performanse upita jer se i replike koriste za postavljanje upita.

Formula replikacije koju Elasticsearch koristi za dosljednost je,

(primarni + broj_of_replika) / 2 + 1

Optimiziranje raspodjele

Na temelju zahtjeva za podacima o proizvodu, možemo klasificirati podatke u tople i hladne. Indeksima kojima se pristupa češće od ostalih može se dodijeliti više čvorova podataka dok indeksi kojima se indeksi rjeđe pristupaju mogu dodijeliti manje resursa. Ova je strategija posebno korisna za pohranjivanje podataka vremenskih serija poput dnevnika aplikacije (npr. ELK).

To se može postići pokretanjem kronjoba koji u pravilnim intervalima premješta indekse u različite čvorove.

Vrući čvor je vrsta podatkovnog čvora koji vrši cijelo indeksiranje unutar klastera. Oni također imaju najnovije indekse, jer se najčešće najčešće ispituju. Kako je indeksiranje CPU i IO intenzivnog rada, ovi poslužitelji moraju biti snažni i podržani priključenom SSD memorijom. Preporučujemo pokretanje najmanje 3 topla čvora za visoku dostupnost. Ovisno o količini nedavnih podataka koje želite prikupiti i upitati, možda ćete trebati povećati taj broj da biste postigli svoje ciljeve izvedbe.

Topli čvor je vrsta čvora podataka koja je dizajnirana za obradu velike količine indeksa samo za čitanje za koje nije vjerojatno da će ih se često ispitivati. Kako su ovi indeksi samo za čitanje, topli čvorovi koriste velike priključene diskove (obično vrteće diskove) umjesto SSD-ova. Kao i kod vrućeg čvora, za visoku dostupnost preporučujemo najmanje 3 Topla čvora. Kao i prije, uz upozorenje da će veće količine podataka možda zahtijevati dodatne čvorove da bi se zadovoljili zahtjevi za radnom snagom. Također imajte na umu da će konfiguracije CPU-a i memorije često trebati odražavati one vaših vrućih čvorova. To se može utvrditi samo ispitivanjem upita sličnih onome što biste imali u proizvodnoj situaciji.

Više pojedinosti o vrućem i toplom čvoru potražite ovdje.

Druga strategija koju možete prilagoditi je arhiviranje indeksa na s3 i vraćanje kad vam trebaju podaci iz tih indeksa. Više o tome možete pročitati ovdje.

Topologija čvora:

Čvrsti elastični čvorovi mogu se podijeliti u tri kategorije glavni čvor, podatkovni čvor, klijentski čvor.

  1. Glavni čvor: Glavni čvor može biti mali ako nije previše Data čvor jer ne pohranjuje nikakve indekse / komadiće. Njegova je odgovornost pohranjivanje detaljnog stanja klastera i pomoć podacima i drugim čvorovima u pretraživanju meta-podataka indeksa / izoštrenih podataka. Elasticsearch bi trebao imati više glavnih čvorova kako bi se izbjegao razdvojeni moždani problem.
  2. Čvor podataka: Čvor podataka odgovoran je za spremanje / postavljanje stvarnih podataka indeksa.
  3. Klijentov čvor: Klijentov čvor koristi se kao proxy za indeksiranje i pretraživanje. To se visoko preporučuje ako se agregati jako koriste. To su posebni čvorovi ElasticSearch koji nisu prihvatljivi ni za podatke ni za master. Klijentski čvorovi su svjesni klastera i stoga mogu djelovati kao pametni uravnotežitelji opterećenja. Možete poslati upite klijentskim čvorovima koji mogu preuzeti skupi zadatak prikupljanja odgovora na rezultate upita iz svakog od čvorova podataka.

dodajte ove postavke u datoteku elastike.yml za odgovarajuće čvorove.

Glavni čvor: node.master: istinski node.data:false
Data čvor: node.master: lažni node.data:true
Klijentov čvor: node.master: lažni node.data:false

Savjeti za rješavanje problema:

Učinak elastične pretrage uvelike ovisi o stroju na kojem je instaliran. CPU, Upotreba memorije i Ulazno / izlazni disk su osnovni podaci operativnog sustava za svaki čvor Elasticsearch. Preporučuje se da pogledate metrike Java Virtual Machine (JVM) kada se CPU poveća. U sljedećem primjeru razlog za šiljak bila je veća aktivnost odvoza smeća.

  1. Tlak gomile: Visoki memorijski tlak djeluje protiv performansi klastera na dva načina: Kako se memorijski tlak povećava na 75% i više, manje memorije ostaje na raspolaganju, a vaš klaster sada treba potrošiti i nekoliko resursa CPU-a za povrat memorije putem odvoza smeća. Ovi CPU ciklusi nisu dostupni za rukovanje korisničkim zahtjevima dok je prikupljanje smeća uključeno. Kao rezultat toga, vrijeme odgovora na korisničke zahtjeve raste kako sustav postaje sve ograničeniji. Ako pritisak u memoriji i dalje raste i dosegne blizu 100%, koristi se mnogo agresivniji oblik odvoza smeća, što će zauzvrat dramatično utjecati na vrijeme reakcije klastera. Metrička vrijednost indeksa Response Times pokazuje da visoki memorijski tlak dovodi do značajnog učinka na performanse.
  2. Rast JVM-ove neheep memorije, jedenje memorije namijenjene predmemoriranju stranice i moguće uzrokovanje žetve OOM-a na razini kernela.
  3. Izbjegavajte split problem mozga. Podijeljeni mozak scenarij je gdje se klaster dijeli. Na primjer, imate 6 čvorova u klasteru. 2 čvorova isključuju se s grozdom, ali još uvijek se mogu vidjeti. Ta dva čvora zatim stvaraju još jedan klaster. Oni će čak izabrati novog gospodara među sobom. Sada imamo dva klastera s istim nazivom, jedan s 4 čvora i drugi s 2 čvora. Svaka osoba ima i glavni čvor. To se naziva problemom podijeljenog mozga s ES klasterima. Da biste to izbjegli, postavite otkrivanje ES parametra.zen.minimum_master_nodes na pola broja čvorova + 1.
  4. Budući da Elasticsearch uvelike koristi uređaje za pohranu, nadziranje I / O diska osigurava ispunjenje ove osnovne potrebe. Postoji mnogo razloga za smanjeni U / I na disku, što se smatra ključnim metrikom za predviđanje mnogih vrsta problema. Dobra je metrička vrijednost za provjeru učinkovitosti indeksiranja i izvedbe upita. Analiza operacija čitanja i pisanja izravno ukazuje na to što sustav treba najviše u određenom slučaju uporabe. Postavke operativnog sustava za U / I diska su osnova za sve ostale optimizacije, ugađanje disk / Ulaza može izbjeći potencijalne probleme. Ako disk I / O još uvijek nije dovoljan, protumjere poput optimizacije broja komada i njihove veličine, zaustavljanja spajanja, zamjene sporih diskova, prelaska na SSD ili dodavanja više čvorova treba procijeniti prema okolnostima koje uzrokuju I / O uska grla.
  5. Za aplikacije koje se oslanjaju na pretraživanje, korisničko iskustvo je visoko povezano s kašnjenjem zahtjeva za pretraživanje. Mnogo je stvari koje mogu utjecati na izvedbu upita, poput konstruiranih upita, nepravilno konfiguriranog klastera Elasticsearch, JVM memorije i sakupljanja smeća, IO diska i tako dalje. Latencija upita mjerna je vrijednost koja izravno utječe na korisnike, stoga obavezno dodajte neka upozorenja.
  6. Većina filtera u Elasticsearchu zadano je spremljena u predmemoriju. To znači da će tijekom prvog izvršenja filtriranog upita Elasticsearch pronaći dokumente koji odgovaraju filtru i izgraditi strukturu nazvanu "bitset" koristeći te podatke. Podaci pohranjeni u bitovima sadrže identifikator dokumenta i odgovara li neki dokument filtru. Naknadna izvršavanja upita s istim filtrom ponovno će upotrijebiti podatke pohranjene u bitsetu i na taj način ubrzati izvršavanje upita spremanjem I / O operacija i CPU ciklusa. Preporučuje se upotreba filtra u upitu. Više pojedinosti potražite ovdje.
  7. Vrijeme osvježavanja i vrijeme spajanja usko su povezani s indeksiranjem performansi, plus utječu na ukupnu učinkovitost klastera. Vrijeme osvježavanja povećava se s brojem operacija datoteka za lucenski indeks (shard).
  8. Omogućivanje sporog evidentiranja upita pomoći će vam u prepoznavanju koji su upiti spora i što se može poduzeti za njihovo poboljšanje, posebno korisno za upite u zamjenske znakove.
  9. Povećajte veličinu neovlaštenih kako biste omogućili maks. Datoteke.
  10. Učinkovitost ElasticSearch može patiti kada OS odluči zamijeniti neiskorištenu memoriju aplikacije. Onemogućite zamjenu postavljanjem postavki razine OS ili postavite sljedeće u ElasticSearch config bootstrap.mlockall: true
  11. Onemogući brisanje svih indeksa upitom zamjenskih znakova. Kako bi se osiguralo da netko ne izvrši operaciju DELETE za sve indekse (* ili _all) postavite action.destructive_requires_name na true.

Prije završetka, evo popisa URL-ova koji su korisni za gledanje mjernih podataka.

  • / _cluster / health? ljepša: Za pokazatelj zdravlja klastera.
  • / _status? ljepši: Za sve informacije o svim indeksima.
  • / _nodes? pretty: Za sve informacije o čvorovima.
  • / _cat / master? ljepotica: Za glavni čvor.
  • / _stats? ljepša: Za dodjelu dijelova, statistika indeksa.
  • / _nodes / stats? ljepša: Za pojedinačnu statistiku čvora, to uključuje jvm, http, io stats za čvor.

Skupljanje metrika Elasticsearch-a podržano je većinom alata za praćenje sustava kao što su Datadog, TICK. Korištenje takvih alata preporučuje se, a stvaranje lijevka jako se preporučuje za kontinuirano nadgledanje elastičnog pretraživanja.

Zaključak:

Elasticsearch je distribuirani mehanizam za pretraživanje i analitiku u čitavom tekstu, koji omogućuje većem broju stanara da pretražuju čitave skupove podataka, bez obzira na veličinu, neviđenom brzinom. Uz svoje mogućnosti pretraživanja cjelovitog teksta, ElasticSearch se predstavlja kao analitički sustav i distribuirana baza podataka. Za početak ElasticSearch ima velike zadane postavke. Ali kad prođete početnu fazu eksperimentiranja, morate potrošiti neko vrijeme da podesite postavke za svoje potrebe. Preporučuje se da ponovno pogledate svoju konfiguraciju kasnije, zajedno sa službenom dokumentacijom, kako biste osigurali da je vaš klaster konfiguriran u skladu s vašim potrebama.