Elastinen haku tuotannossa - käyttöönoton parhaat käytännöt

Elasticsearch on erittäin optimoitu hakukone nykyaikaiseen data-analytiikkaan.

Elasticsearch on uskomaton reaaliaikainen haku- ja analysointimoottori. Se on rakennettu Apache Lucenen päälle. Se on jaettu, RESTful, helppo aloittaa käyttö ja erittäin saatavissa. Elastisen haun käyttötapauksiin sisältyy haun virittäminen, tapahtumien seuranta ja virheiden havaitseminen, sisällön etsiminen, lokin analysointi, sumea haku, tapahtumadatan yhdistäminen, datan visualisointi. Elastinen haku ja muu joustava pino ovat osoittautuneet erittäin monipuolisiksi, ja kuten yllä olevista käyttötapauksista näet, on olemassa useita tapoja integroida Elasticsearch tuotteisiisi tänään toimittamassa muodossa ja lisätä siihen ymmärrystä.

Käytämme sitä voimakkaasti Botmetricin hakuun ja analytiikkaan, indeksoimme noin miljardia asiakirjaa päivässä ja käytämme erittäin monimutkaisia ​​yhdistelmiä tietojen visualisointiin reaaliajassa.

Sovelluksen käynnistäminen vs. sen suorittaminen tuotannossa ja ylläpidossa ovat täysin erilaisia. Tämä arikaali kattaa monet näistä tekijöistä tosielämän kokemuksista ja ovat yleisiä peruskohteita, jotka sinun tulisi harkita johtamalla Elasticsearchia tuotannossa.

Muisti:

Elasticsearch ja Lucene on kirjoitettu Java-kielellä, mikä tarkoittaa, että sinun on oltava varovainen kassatilan ja JVM-tilastotietojen suhteen. Mitä enemmän kasa Elasticsearch tarjoaa, sitä enemmän muistia se voi käyttää suodattimiin ja muuhun välimuistiin kyselyn suorituskyvyn parantamiseksi. Mutta huomaa, että liian suuri kasa voi johtaa pitkiin roskien keräystaukoihin. Älä aseta Xmx-arvoa ylärajan yläpuolelle, jota JVM käyttää pakatun objektin osoittimiin (pakatut Hups); tarkka raja vaihtelee, mutta on lähellä 32 Gt.

Yleinen ongelma on liian suuren kasan määrittäminen. Sinulla on 64 Gt: n kone - ja golly, haluat antaa Elasticsearchille kaikki 64 Gt muistia. Lisää on parempi! Kasa on ehdottomasti tärkeä joustavalle etsinnälle. Sitä käyttävät monet muistin sisäiset tietorakenteet nopean toiminnan aikaansaamiseksi. Mutta tämän sanottua, on olemassa toinen suuri muistin käyttäjä, joka on tyhjä: OS-tiedoston välimuisti.

Lucene on suunniteltu hyödyntämään taustalla olevaa käyttöjärjestelmää muistin tietorakenteiden välimuistiin tallentamiseksi. Lucene-segmentit tallennetaan yksittäisiin tiedostoihin. Koska segmentit ovat muuttumattomia, nämä tiedostot eivät muutu koskaan. Tämä tekee niistä erittäin välimuistiystävällisiä, ja taustalla oleva käyttöjärjestelmä pitää mielellään kuumat segmentit muistissa nopeamman pääsyn vuoksi. Nämä segmentit sisältävät sekä käänteisen hakemiston (koko tekstiä varten) että doc-arvot (yhdistelmiä varten). Lucenen suorituskyky perustuu tähän vuorovaikutukseen käyttöjärjestelmän kanssa. Mutta jos annat kaiken käytettävissä olevan muistin Elasticsearchin kasaan, käyttöjärjestelmän tiedostojen välimuistissa ei jää jäljelle. Tämä voi vaikuttaa vakavasti suorituskykyyn. Tavallinen suositus on antaa 50% käytettävissä olevasta muistista Elasticsearch-kasaan, kun taas toinen 50% jätetään vapaaksi. Sitä ei käytetä; Lucene kuluttaa mielellään kaiken, mitä tiedostovälimuistissa on jäljellä. Elastisen haun kasa voidaan konfiguroida seuraavilla tavoilla,

vie ES_HEAP_SIZE = 10 g

tai

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

PROSESSORI:

Elastinen haku tukee aggregaatioita ja suodatettuja kyselyitä. Monimutkaisten suodatettujen kyselyiden suorittaminen, intensiivinen indeksointi, perkollaatio ja indeksejä koskevat kyselyt vaativat raskaita suorittimia, joten oikean hakeminen on kriittistä. On ymmärrettävä suorittimen spesifikaatiot ja kuinka ne käyttäytyvät Java: n kanssa, kun kyselyt suoritetaan JVM: llä.

Jokaisessa uima-altaassa on useita säikeitä, jotka voidaan konfiguroida, ja jonossa on. Tämän muuttamista ei suositella, ellei sinulla ole erityisiä vaatimuksia, koska Elasticsearch jakaa ytimet dynaamisesti.

Kiertoaltaan tyypit:

Elasticsearchissa on 3 tyyppistä säieallasta.

  1. Välimuisti: Välimuistiin tallennettu säiepooli on rajaton säiepooli, joka kutistaa langan, jos vireillä olevia pyyntöjä on. Tätä ketjuvarastoa käytetään estämään tälle poolille lähetettyjen pyyntöjen estäminen tai hylkääminen. Tämän ketjuvarannon käyttämättömät ketjut lopetetaan hengissä pysymisen jälkeen (oletusasetus on viisi minuuttia). Välimuistissa oleva säieallas on varattu geneeriselle säieallaselle.
  2. Kiinteä: Kiinteä säieallas pitää kiinni kiinteän kokoisia ketjuja käsittelemään pyyntöjä jonolla (valinnaisesti rajattuna) odotettavissa oleville pyynnöille, joilla ei ole ketjuja niiden palvelemiseksi. Kokoparametri ohjaa lankojen lukumäärää, ja oletusarvo on ydinten lukumäärä kertaa 5.
  3. Skaalaus: Skaalautuva säiepooli pitää sisällään dynaamisen määrän lankoja. Tämä luku on verrannollinen työmäärään ja vaihtelee välillä 1 ja kokoparametrin arvon välillä.

Elasticsearch jakaa CPU: n käytön erityyppisiksi säiepooliksi:

  • yleinen: standarditoiminnoille, kuten etsinnälle ja ketjuvarastotyypille, välimuisti.
  • hakemisto: hakemisto- / poisto-toimintoihin. Kiertoaltaan tyyppi on kiinteä.
  • haku: laskenta- / hakutoiminnot. Kiertoaltaan tyyppi on kiinteä.
  • get: saada operaatioita. Kiertoaltaan tyyppi on kiinteä.
  • irtotavara: irtotavaratoimintoihin, kuten bulkkien indeksointi. Kiertoaltaan tyyppi on kiinteä. Paras joukkoasiakirjojen kokoonpano riippuu klusterin kokoonpanosta. Tämä voidaan tunnistaa kokeilemalla useita arvoja.
  • perkolaatti: suolautumiseen. Kiertoaltaan tyyppi on kiinteä.
  • päivitä: Päivitä toiminnot. Kierrealtaan tyyppi on skaalautuva.

Tietty säiepooli voidaan muuttaa asettamalla sen tyyppikohtaiset parametrit.

Lue lisää https://www.elastic.co/guide/fi/elasticsearch/reference/2.2/modules-threadpool.html#types

Varjostimen koko:

Varjostin on yksikkö, jolla Elasticsearch jakaa tietoja klusterissa. Nopeus, jolla elastinen haku voi liikkua sirpaleiden ympärillä datan tasapainottamisessa, esim. epäonnistumisen jälkeen riippuu sirpaleiden koosta ja lukumäärästä sekä verkon ja levyn suorituskyvystä.

Elasticsearch-sovelluksessa jokainen kysely suoritetaan yhdellä säikeellä per shard. Useita sirpaleita voidaan kuitenkin käsitellä rinnakkain, samoin kuin useat kyselyt ja aggregaatiot samaa shardia vastaan.

Tämä tarkoittaa, että kyselyn vähimmäisviive, kun välimuistiin puuttumista ei ole, riippuu tiedoista, kyselyn tyypistä ja sirpaleen koosta. Useiden pienten sirpaleiden kysely tekee prosessoinnista nopeampaa, mutta koska useita muita tehtäviä on pidettävä jonossa ja käsiteltävä peräkkäin, se ei välttämättä ole nopeampaa kuin pienemmän määrän suurempien sirpaleiden kyselyä. Jos sinulla on paljon pieniä sirpaleita, se voi myös vähentää kyselyn suorituskykyä, jos samanaikaisia ​​kyselyjä on useita.

Jokaisella sirpaleella on tietoja, jotka on pidettävä muistissa, ja ne käyttävät kasa-tilaa. Tähän sisältyy tietorakenteet, jotka pitävät tietoa sharditasolla ja myös segmenttitasolla sen määrittelemiseksi, missä data levyllä on. Näiden tietorakenteiden kokoa ei ole kiinteä ja se vaihtelee käyttötapauksesta riippuen. Yksi segmenttiin liittyvien yleiskustannusten tärkeä ominaisuus on kuitenkin, että se ei ole tiukasti verrannollinen segmentin kokoon. Tämä tarkoittaa, että suuremmilla segmenteillä on vähemmän yleiskustannuksia tietomäärää kohti pienempiin segmentteihin verrattuna. Ero voi olla huomattava. Oikean määrän sirpaleiden valitseminen on monimutkaista, koska et koskaan tiedä kuinka monta asiakirjaa saat ennen aloittamista. Jos sinulla on paljon sirpaleita, se voi olla klusterille hyvä ja kauhea. Indeksit ja sirpaleiden hallinta voivat ylikuormittaa isäntäsolmun, mikä saattaa muuttua reagoimattomaksi, mikä johtaa omituiseen ja ikävään käyttäytymiseen. Sijoita pääsolmuja riittävästi resursseja selviytymään klusterin koosta.

Huono asia on, että sirpaleiden lukumäärä on muuttumaton ja se määritetään indeksiä luotaessa. Kun hakemisto on luotu, ainoa tapa muuttaa sirpaleiden lukumäärää on poistaa indeksit, luoda ne uudelleen ja indeksoida uudelleen.

replikointi

Elastinen haku tukee replikointia, dataa replikoidaan datasolmujen kesken, joten solmun menetys ei johtaisi tietojen menetykseen. Oletuksena replikointikerroin on 1, mutta tuotevaatimuksista riippuen sitä voidaan kasvattaa. Mitä enemmän jäljennöksiä, sitä katastrofienkestävämpi tieto on. Toinen etuna siitä, että sinulla on enemmän replikoita, on, että jokaisessa solmussa on replica shard, mikä parantaa kyselyn suorituskykyä, koska myös replikoja käytetään kyselyihin.

Elastinen kaava, jota Elasticsearch käyttää johdonmukaisuuteen, on,

(ensisijainen + lukumäärä_parannuksia) / 2 + 1

Jakamisen optimointi

Tuotetietovaatimusten perusteella voimme luokitella tiedot kuumaan ja kylmään. Indekseille, joihin pääsyä useammin kuin toisia, voidaan osoittaa enemmän datasolmuja, kun taas indekseille, joille harvemmin käytetään indeksejä, voi olla vähemmän resursseja. Tämä strategia on erityisen hyödyllinen aikasarjojen, kuten sovelluslokkien (esimerkiksi ELK) tallentamiseksi.

Tämä voidaan saavuttaa ajamalla crotjob, joka siirtää indeksit eri solmuihin säännöllisin väliajoin.

Kuuma solmu on tietyn tyyppinen datasolmu, joka suorittaa kaiken indeksoinnin klusterissa. Niillä on myös viimeisimmät indeksit, koska niitä yleensä kysytään yleisimmin. Koska indeksointi on CPU- ja IO-intensiivistä toimintaa, näiden palvelimien on oltava tehokkaita ja varustettuna liitteenä olevalla SSD-tallennuksella. Suosittelemme käyttämään vähintään 3 kuumaa solmua korkean käytettävyyden varmistamiseksi. Riippuen viimeaikaisten tietojen määrästä, jonka haluat kerätä ja kysyä, saatat joutua nostamaan tätä määrää suorituskykytavoitteidesi saavuttamiseksi.

Lämmin solmu on tietosolmun tyyppi, joka on suunniteltu käsittelemään suurta määrää vain luku -tyyppisiä indeksejä, joita ei todennäköisesti kysytä usein. Koska nämä indeksit ovat vain luku -tyyppisiä, lämmin solmu käyttää yleensä suuria liitettyjä levyjä (yleensä pyörivää levyjä) SSD-levyjen sijasta. Kuten kuuma solmu, suosittelemme vähintään 3 lämminsolmua korkean saatavuuden saavuttamiseksi. Ja kuten aiemmin, huomautuksella, että suuret tietomäärät saattavat edellyttää lisäsolmuja suorituskykyvaatimusten täyttämiseksi. Huomaa myös, että suorittimen ja muistin kokoonpanojen on usein heijastettava kuumien solmujen asetuksia. Tämä voidaan määrittää vain testaamalla kyselyillä, jotka ovat samanlaisia ​​kuin mitä kokeisit tuotantotilanteessa.

Lisätietoja kuumasta ja lämpimästä solmusta on täällä.

Toinen strategia, jota voit mukauttaa, on arkistoida indeksit s3: een ja palauttaa, kun tarvitset tietoja näistä indekseistä. Voit lukea lisää siitä täältä.

Solmun topologia:

Elastinenhakusolmut voidaan jakaa kolmeen luokkaan isäntäsolmu, datasolmu, asiakassolmu.

  1. Pääsolmu: Pääsolmu voi olla pieni, jos se ei ole myöskään datasolmu, koska se ei tallenna indeksejä / siruja. Sen vastuulla on tallentaa yksityiskohtainen klusteritila ja auttaa tietoja ja muita solmuja indeksien / sirpaleiden metatietohaussa. Elastisessa haussa tulisi olla useita isäntäsolmuja, jotta vältetään jaetut aivo-ongelmat.
  2. Tietosolmu: Tietosolmu vastaa todellisen hakemistotiedon tallentamisesta / kyselystä.
  3. Asiakasolmu: Asiakasolmua käytetään välityspalvelimena indeksointiin ja hakuihin. Tämä on erittäin suositeltavaa, jos yhdistelmiä käytetään voimakkaasti. Nämä ovat erityisiä ElasticSearch-solmuja, jotka eivät ole data- tai isäntäkelpoisia. Asiakasolmut ovat klusteritietoisia ja voivat siksi toimia älykkäinä kuormituksen tasapainottajina. Voit lähettää kyselysi asiakassolmuille, jotka voivat sitten ottaa kalliin tehtävän kerätä vastauksia kyselyn tuloksiin jokaisesta datasolmusta.

lisää nämä asetukset elastsearch.yml-tiedostoon vastaaville solmuille.

Pääsolmu: node.master: true node.data:false
Tietosolmu: node.master: false node.data:true
Asiakasolmu: node.master: false node.data:false

Vianmääritysvihjeitä:

Elastisen haun suorituskyky riippuu suuresti koneesta, johon se on asennettu. CPU, muistin käyttö ja levyn I / O ovat käyttöjärjestelmän perusmittarit jokaiselle Elastinen haku -solmulle. On suositeltavaa tutkia JVM (Java Virtual Machine) -mittarit, kun suorittimen käyttö nousee. Seuraavassa esimerkissä piikin syy oli korkeampi jätekeräysaktiivisuus.

  1. Kasainipaine: Korkea muistinpaine vaikuttaa klusterin suorituskykyyn kahdella tavalla: Kun muistin paine nousee vähintään 75%: iin, vähemmän muistia on käytettävissä, ja klusterisi on nyt myös käytettävä joitain CPU-resursseja muistin palauttamiseen roskien keräämisen kautta. Nämä CPU-jaksot eivät ole käytettävissä käyttäjän pyyntöjen käsittelemiseen roskienkeräyksen ollessa päällä. Seurauksena on, että käyttäjän pyyntöjen vastausajat pitenevät, kun järjestelmä rajoittaa resurssien käyttöä. Jos muistin paine jatkaa nousuaan ja saavuttaa lähes 100%, käytetään paljon aggressiivisempaa jätekeräysmuotoa, mikä puolestaan ​​vaikuttaa klusterin vasteaikoihin dramaattisesti. Hakemisto Response Times -metriikka osoittaa, että korkea muistipaine johtaa merkittävään suorituskykyvaikutukseen.
  2. Kasvu JVM: n ei-kasa-muistissa, syömällä sivuvälimuistiin tarkoitettu muisti ja mahdollisesti aiheuttaen ytimen tason OOM-nouton.
  3. Vältä jakautuneita aivo-ongelmia. Jaetut aivot ovat skenaario, jossa klusteri jakautuu. Esimerkiksi, sinulla on 6 solmun klusteria. 2 solmua irtoavat klusterista, mutta pystyvät silti näkemään toisensa. Nämä 2 solmua luovat sitten uuden klusterin. He jopa valitsevat keskuudestaan ​​uuden mestarin. Meillä on nyt kaksi samannimistä klusteria, toisessa 4 solmua ja toisessa 2 solmua. Jokaisella on myös isäntäsolmu. Tätä kutsutaan jaettujen aivojen ongelmaksi ES-klusterien kanssa. Tämän välttämiseksi aseta ES-parametri discovery.zen.minimum_master_nodes puoleen solmujen lukumäärästä + 1.
  4. Koska Elasticsearch käyttää paljon tallennuslaitteita, levyn I / O-valvonta varmistaa, että tämä perustarve täyttyy. Levyjen I / O-määrän vähentymiseen on monia syitä. Sitä pidetään avainmittarina monenlaisten ongelmien ennustamisessa. Se on hyvä mittari tarkistaa indeksoinnin ja kyselyn tehokkuus. Lukemis- ja kirjoitusoperaatioiden analysointi osoittaa suoraan, mitä järjestelmä tarvitsee tietyssä käyttötapauksessa eniten. Levyn I / O-käyttöjärjestelmän asetukset ovat perusta kaikille muille optimoinneille. Levyn I / O: n virittäminen voi välttää mahdolliset ongelmat. Jos levyn I / O ei edelleenkään riitä, vastatoimenpiteitä, kuten sirpaleiden lukumäärän ja niiden koon optimointi, kuristimien yhdistäminen, hitaiden levyjen korvaaminen, siirtyminen SSD-levyille tai lisää solmuja, olisi arvioitava I / O: n aiheuttavien olosuhteiden mukaan. pullonkauloja.
  5. Haussa luottavien sovellusten käyttäjäkokemus korreloi voimakkaasti hakupyyntöjen viiveen kanssa. On monia asioita, jotka voivat vaikuttaa kyselyn suorituskykyyn, kuten rakennetut kyselyt, väärin määritetyt Elasticsearch-klusterit, JVM-muisti- ja roskien keräysongelmat, levyn IO ja niin edelleen. Kyselyviive on mittari, joka vaikuttaa suoraan käyttäjiin, joten varmista, että lisäät siihen joitain ilmoituksia.
  6. Suurin osa Elasticsearch-suodattimista on välimuistissa oletusarvoisesti. Tämä tarkoittaa, että suodatetun kyselyn ensimmäisen suorituksen aikana Elasticsearch löytää suodattinta vastaavat asiakirjat ja rakentaa bitsetti-nimisen rakenteen, joka käyttää näitä tietoja. Bittisarjaan tallennetut tiedot sisältävät asiakirjan tunnisteen ja vastaako tietty asiakirja suodatinta. Myöhemmät, samalla suodattimella varustettujen kyselyjen suoritukset käyttävät bittisarjaan tallennettua tietoa uudelleen, mikä tekee kyselyn suorittamisen nopeammaksi tallentamalla I / O-toiminnot ja CPU-syklit. Suodattimen käyttämistä kyselyssä suositellaan. Katso lisätietoja täältä.
  7. Päivitysaika ja yhdistämisaika liittyvät läheisesti indeksointitehokkuuteen, plus ne vaikuttavat klusterin yleiseen suorituskykyyn. Päivitysaika kasvaa lukene-hakemiston (shard) tiedostotoimintojen lukumäärän kanssa.
  8. Hitaan kyselylokin käyttöönotto auttaa tunnistamaan, mitkä kyselyt ovat hitaita ja mitä voidaan tehdä niiden parantamiseksi, ja se on erityisen hyödyllinen jokerimerkintöihin.
  9. Suurenna ulimit-kokoa salliaksesi maksimitiedostot.
  10. ElasticSearch-suorituskyky voi kärsiä, kun käyttöjärjestelmä päättää vaihtaa käyttämättömän sovellusmuistin. Poista vaihto vaihtamalla asettamalla käyttöjärjestelmän tason asetukset tai asettamalla seuraavat ElasticSearch-määritykset: bootstrap.mlockall: true
  11. Poista kaikkien indeksien poistaminen jokerimerkillä. Aseta action.destructive_requires_name -asetukseksi totta, että joku ei anna POISTA-operaatiota kaikissa hakemistoissa (* tai _all).

Ennen kuin lopetat, tässä on luettelo URL-osoitteista, jotka ovat hyödyllisiä metrien seuraamiseksi.

  • / _klusteri / terveys? kaunis: Klusterin terveysindikaattorille.
  • / _status? kaunis: Kaikista tiedoista kaikista indekseistä.
  • / _nodes? pretty: Kaikkia tietoja solmuista.
  • / _cat / master? kaunis: Pääsolmulle.
  • / _stats? sievä: Shard allokaatiota varten indeksitilastot.
  • / _nodes / stats? pretty: Yksittäisten solmujen tilastoihin tämä sisältää solmun jvm, http, io-tilastot.

Elastisen haun metrien yhdistämistä tukee useimmat järjestelmänvalvontatyökalut, kuten Datadog, TICK. Tällaisten työkalujen käyttämistä suositellaan, ja suppilon luominen on erittäin suositeltavaa elastisen haun jatkuvalle seurannalle.

johtopäätös:

Elasticsearch on hajautettu täystekstinen haku- ja analysointimoottori, jonka avulla useat vuokralaiset voivat hakea koko tietokokonaisuudestaan ​​koosta riippumatta ennennäkemättömällä nopeudella. Kokotekstihakuominaisuuksiensa lisäksi ElasticSearch toimii myös analysointijärjestelmänä ja hajautettuna tietokannana. ElasticSearch on suuri oletusasetukset aloittamiseen. Mutta kun olet aloittanut ensimmäisen kokeiluvaiheen, sinun on vietettävä aikaa säätääksesi asetuksia tarpeitasi varten. On suositeltavaa tarkistaa kokoonpano myöhemmin yhdessä virallisten dokumenttien kanssa, jotta voidaan varmistaa, että klusteri on määritetty vastaamaan tarpeitasi.