suurten tietokokonaisuuksien etsiminen ja hakeminen Elasticsearchissa tehokkaasti

tähän viestiin käytämme isännöityä Elasticsearchia Qbox.io. voit rekisteröityä tai käynnistää klusterin täällä, tai klikkaa “Aloita” otsikon navigointi. Jos tarvitset apua perustamiseen, katso ” Provisioning a Qbox Elasticsearch Cluster.”

tavoitteemme

Qbox tarjoaa avaimet käteen-ratkaisun Elasticsearch, Kibana ja monet Elasticsearch analysis and monitoring plugins. Opetusohjelman tavoitteena on käyttää Qboxia osoittamaan hakemalla suuria tietopaloja skannauksen ja Vierityspyyntöjen avulla. Perustamme Logstashin erilliseen solmuun/koneeseen kerätäksemme Twitter streamin ja käyttääksemme Qbox provisioned Elasticsearchia pelataksemme tehokkaan skannauksen ja vierityksen API: n ympärillä.

HIRVIPINON kokoonpanossa on kolme pääosaa:

  • Elasticsearch: sitä käytetään tallentaa kaikki sovellus-ja valvontalokit(Provised by Qbox).
  • Logstash: palvelinkomponentti, joka käsittelee saapuvia lokeja ja syötteitä ES: lle.
  • Kibana(valinnainen): Web-käyttöliittymä hakuun ja visualisointiin lokit (Provised by Qbox).

edellytykset

Elasticsearch-palvelimesi vaatima suoritin -, RAM-ja tallennustilan määrä riippuu siitä, kuinka paljon lokeja aiot kerätä. Tämän opetusohjelman, käytämme Qbox provisioned Elasticsearch kanssa seuraavat vähimmäisvaatimukset:

  • tarjoaja: AWS
  • versio: 5.1.1
  • RAM: 1GB
  • suoritin: vCPU1
  • jäljennökset: 0

yllä olevat tiedot voidaan muuttaa haluamiesi vaatimusten mukaan. Valitse tarpeisiisi sopivat nimet, versiot, alueet. Tässä esimerkissä käytimme Elasticsearch-versiota 5.1.1, uusin versio on 5.3. Tuemme kaikkia Elasticsearchin versioita qboxissa. (Lisätietoja tärkeimmistä eroista 2.x ja 5.X, klikkaa tästä.)

Elasticsearch-palvelimemme lisäksi tarvitsemme erillisen logstash-palvelimen, joka käsittelee twitter API: sta tulevan twitter-virran ja lähettää sen Elasticsearch-palvelimelle. Yksinkertaisuuden ja testauksen vuoksi logstash-palvelin voi toimia myös itse asiakaspalvelimena. Qboxin tarjoaman Elasticsearch Clusterin päätepiste – ja Kuljetusosoitteet ovat seuraavat:

yhteinen_1.png

päätepiste: REST API

https://ec18487808b6908009d3:[email protected]:32563

tunnistautuminen

  • käyttäjätunnus = ec18487808b6908009d3
  • salasana = efcec6a1e0

TRANSPORT (kotoperäinen Jaava)

eb843037.qb0x.com:30543

Huomautus: Varmista, että Qbox Elasticsearch Clusterin logstash-palvelimen IP on valittu valkoiseksi.

Asenna Lokikirja

Lataa ja asenna Julkinen allekirjoitusavain:

wget -qO - https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

käytämme Logstash version 2.4.x: ää yhteensopivana meidän Elasticsearch version 5.1.x: n kanssa. Joustavaan yhteisön Tuotetukimatriisiin voidaan viitata mahdollisten versiokysymysten selvittämiseksi.

lisää arkiston määritelmä/etc / apt / – lähteisiisi.luettelotiedosto:

echo "deb https://packages.elastic.co/logstash/2.4/debian stable main" | sudo tee -a /etc/apt/sources.list

suorita sudo apt-get update ja arkisto on käyttövalmis. Voit asentaa sen:

sudo apt-get update && sudo apt-get install logstash

vaihtoehtoisesti tukkipesutervan voi ladata myös Elastisen Tuotejulkaisusivustolta. Sitten, vaiheet perustaa ja käynnissä logstash ovat melko yksinkertaisia:

  • Lataa ja pura Logstash
  • valmista logstash.conf config-tiedosto
  • Suorita bin/logstash -f logstash.conf -t tarkistaaksesi config (logstash.conf)
  • Run bin/logstash -f logstash.conf

Configure Logstash (Twitter Stream)

Logstash-asetustiedostot ovat JSON-muodossa, ja ne sijaitsevat /etc/logstash/conf.d. Kokoonpano koostuu kolmesta osasta: tulot, suodattimet ja lähdöt.

tarvitsemme luvan ottaa dataa Twitteristä sen API: n kautta. Tämä osa on helppo:

  1. Kirjaudu Twitter-tilillesi
  2. mene https://dev.twitter.com/apps/
  3. Luo uusi Twitter-sovellus (tässä annan sovelluksen nimeksi Twitter-Qbox-Stream).

t1.png

kun olet onnistunut luomaan Twitter-sovelluksen, saat seuraavat parametrit “Keys and Access Tokens”:

  1. Kuluttajaavain (API-avain)
  2. Kuluttajasalaisuus (API-salaisuus)
  3. pääsyavain
  4. pääsyavain salainen

t2.png

olemme nyt valmiita luomaan Twitterin datapolun (stream) Twitterin palvelimilta koneeseemme. Käytämme edellä mainittuja neljää parametria (consumer key, consumer secret, access token, access token secret) määrittääksemme twitter-syötteen lokinpesua varten.

luodaan asetustiedosto nimeltä 02-twitter-input.conf ja perustetaan “twitter” – syöte:

sudo vi /etc/logstash/conf.d/02-twitter-input.conf

lisää seuraavat syöteasetukset:

input { twitter { consumer_key => "BCgpJwYPDjXXXXXX80JpU0" consumer_secret => "Eufyx0RxslO81jpRuXXXXXXXMlL8ysLpuHQRTb0Fvh2" keywords => oauth_token => "193562229-o0CgXXXXXXXX0e9OQOob3Ubo0lDj2v7g1ZR" oauth_token_secret => "xkb6I4JJmnvaKv4WXXXXXXXXS342TGO6y0bQE7U" }}

Tallenna ja lopeta tiedosto 02-twitter-input.conf.

tämä määrittää twitter-syötteen, joka suodattaa twiittejä avainsanoilla “mobile”, “java”, “android”, “elasticsearch”, “search” ja siirtää ne logstash-ulostuloon. Tallenna ja lopeta. Lopuksi luomme asetustiedoston nimeltä 30-elasticsearch-output.conf:

sudo vi /etc/logstash/conf.d/30-elasticsearch-output.conf

lisää seuraavat Tulostusasetukset:

output { elasticsearch { hosts => user => "ec18487808b6908009d3" password => "efcec6a1e0" index => "twitter-%{+YYYY.MM.dd}" document_type => "tweet" } stdout { codec => rubydebug }}

Tallenna ja poistu. Tämä tuloste määrittää periaatteessa Logstashin tallentamaan Twitterin lokitiedot Elasticsearchiin, joka on käynnissä https://eb843037.qb0x.com:30024/, Twitterin mukaan nimettyyn indeksiin.

jos olet ladannut logstash tar: n tai zip: n, voit luoda logstash: in.conf tiedosto ottaa tulo, suodatin ja Lähtö kaikki yhdessä paikassa.

sudo vi LOGSTASH_HOME/logstash.conf

lisää seuraava Tulo-ja tulostuskokoonpano logstashiin.conf

input { twitter { consumer_key => "BCgpJwYPDjXXXXXX80JpU0" consumer_secret => "Eufyx0RxslO81jpRuXXXXXXXMlL8ysLpuHQRTb0Fvh2" keywords => oauth_token => "193562229-o0CgXXXXXXXX0e9OQOob3Ubo0lDj2v7g1ZR" oauth_token_secret => "xkb6I4JJmnvaKv4WXXXXXXXXS342TGO6y0bQE7U" }}output { elasticsearch { hosts => user => "ec18487808b6908009d3" password => "efcec6a1e0" index => "twitter-%{+YYYY.MM.dd}" document_type => "tweet" } stdout { codec => rubydebug }}

testaa Logstash-asetuksesi tällä komennolla:

sudo service logstash configtest

sen pitäisi näyttää kokoonpano OK, jos syntaksivirheitä ei ole. Muussa tapauksessa yritä lukea virhetuloste nähdäksesi, mitä vikaa Logstash-asetuksessasi on.

Käynnistä Logstash uudelleen ja ota se käyttöön, jotta asetusmuutoksemme voidaan toteuttaa:

sudo service logstash restartsudo update-rc.d logstash defaults 96 9

jos olet ladannut logstash tar-tai zip-tiedoston, se voidaan suorittaa komennolla

bin/logstash -f logstash.conf

lukuisia vastauksia saadaan. Asiakirjan rakenne on seuraava:

{ "text": "Learn how to automate anomaly detection on your #Elasticsearch #timeseries data with #MachineLearning:", "created_at": "2017-05-07T07:54:47.000Z", "source": "<a href="%5C">Twitter for iPhone</a>", "truncated": false, "language": "en", "mention": , "retweet_count": 0, "hashtag": , "location": { "lat": 33.686657, "lon": -117.674558 }, "place": { "id": "74a60733a8b5f7f9", "name": "elastic", "type": "city", "full_name": "San Francisco, CA", "street_address": null, "country": "United States", "country_code": "US", "url": "https://api.twitter.com/1.1/geo/id/74a60733a8b5f7f9.json" }, "link": , "user": { "id": 2873953509, "name": "Elastic", "screen_name": "elastic", "location": "SF, CA", "description": "The company behind the Elastic Stack (#elasticsearch, #kibana, Beats, #logstash), X-Pack, and Elastic Cloud" }}

Elasticsearch mahdollistaa sivutuksen lisäämällä koon ja from-parametrin. Esimerkiksi jos haluat hakea tuloksia erissä 5 alkaen 3. sivulta (eli Näytä tulokset 11-15), et tekisi:

curl -XGET 'ES_HOST:ES_PORT/twitter/tweet/_search?size=5&from=10'

se tulee kuitenkin kalliimmaksi, kun siirrymme yhä kauemmas tulosluetteloon. Joka kerta, kun soitamme yhden näistä puheluista, suoritamme etsintäoperaation uudelleen, pakotamme Lucenen menemään ja pisteyttämään kaikki tulokset uudelleen, asettamaan ne paremmuusjärjestykseen ja sitten hylkäämään ensimmäiset 10 (tai 10000, jos pääsemme niin pitkälle). Helpompi vaihtoehto on scan and scroll API. Ajatuksena on ajaa varsinainen kysely kerran ja sitten Elastinen piilottaa tuloksen jonnekin ja antaa meille “access token” mennä takaisin ja saada ne. Sitten kutsumme scroll API päätepiste sanoi token saada seuraavan sivun tuloksia.

jotta voidaan käyttää vieritystä, alkuperäisen hakupyynnön tulee määrittää vieritysparametri kyselymerkkijonossa, joka kertoo Elasticsearchille, kuinka kauan sen tulee pitää “hakuyhteys” elossa, esim.?vieritys=1 m.

curl -XPOST 'ES_HOST:ES_PORT/twitter-*/tweet/_search?scroll=1m&pretty' -H 'Content-Type: application/json' -d '{ "size": 100, "query": { "match" : { "text" : "elasticsearch" } }}'

yllä olevan pyynnön tulos sisältää _scroll_id-tunnuksen, joka tulee siirtää vieritysrajapintaan seuraavan tuloserän hakemiseksi.

curl -XPOST 'ES_HOST:ES_PORT/_search/scroll?pretty' -H 'Content-Type: application/json' -d '{ "scroll" : "1m", "scroll_id" : "DXF1ZXJ5DKJ56hghFHFDJgBAAAAAAAArknJBJsbjYtZndUQlNsdDcwakFSDSSXSQ=="}'

kokoparametrin avulla voit määrittää palautettavien osumien enimmäismäärän kunkin tuloserän yhteydessä. Jokainen puhelu scroll API palauttaa seuraavan erän tuloksia, kunnes ei ole enää tuloksia jäljellä palata, eli osumat array on tyhjä. Muutamia tärkeitä kohtia harkitsemaan koskien Selaa ja Scan API ovat seuraavat:

  • alkuperäinen hakupyyntö ja jokainen sitä seuraava vierityspyyntö palauttaa uuden _scroll_id, vain viimeisintä _scroll_id tulee käyttää.
  • jos pyynnössä täsmennetään aggregaatiot, vain alkuperäinen hakuvastaus sisältää aggregointitulokset.
  • Vierityspyynnöissä on optimoinnit, jotka nopeuttavat niitä, kun lajittelujärjestys on _doc. Jos haluat iteroida kaikki asiakirjat järjestyksestä riippumatta, tämä on tehokkain vaihtoehto:
curl -XGET 'ES_HOST:ES_PORT/_search?scroll=1m&pretty' -H 'Content-Type: application/json' -d '{ "sort": }'

Hakuyhteys

vieritysparametri kertoo Elasticsearchille, kuinka kauan sen pitäisi pitää hakuyhteys elossa. Sen arvon (esim.1m) ei tarvitse olla tarpeeksi pitkä kaikkien tietojen käsittelyyn, sen täytyy vain olla tarpeeksi pitkä edellisen tuloserän käsittelyyn. Jokainen vierityspyyntö asettaa uuden vanhenemisajan.

Clear Scroll API

Hakuyhteys poistetaan automaattisesti, kun vierityksen aikalisä on ylitetty. Kuitenkin pitämällä kääröt auki on kustannuksia (käsitellään myöhemmin suorituskykyä osiossa) joten kääröt on nimenomaisesti tyhjennettävä heti, kun vieritys ei ole enää käytössä clear-scroll API:

curl -XDELETE 'ES_HOST:ES_PORT/_search/scroll?pretty' -H 'Content-Type: application/json' -d '{ "scroll_id" : }'

Useita vieritystunnuksia voidaan siirtää array:

curl -XDELETE 'ES_HOST:ES_PORT/_search/scroll?pretty' -H 'Content-Type: application/json' -d '{ "scroll_id" : }'

kaikki hakukontekstit voidaan tyhjentää k_aikki-parametrilla:

curl -XDELETE 'ES_HOST:ES_PORT/_search/scroll/_all?pretty'

viipaloitu vieritys

Vierityskyselyt, jotka palauttavat paljon asiakirjoja, voidaan jakaa useiksi siivuiksi, jotka voidaan kuluttaa itsenäisesti:

 curl -XGET 'ES_HOST:ES_PORT/twitter-*/tweet/_search?scroll=1m&pretty' -H 'Content-Type: application/json' -d '{ "slice": { "id": 0, "max": 2 }, "query": { "match" : { "text" : "elasticsearch" } }}'
curl -XGET 'ES_HOST:ES_PORT/twitter-*/tweet/_search?scroll=1m&pretty' -H 'Content-Type: application/json' -d '{ "slice": { "id": 1, "max": 2 }, "query": { "match" : { "text" : "elasticsearch" } }}'

ensimmäisen pyynnön tulos palauttaa ensimmäiseen viipaleeseen kuuluvat asiakirjat (id: 0) ja toisen pyynnön tulos palauttaa toiseen viipaleeseen kuuluvat asiakirjat. Koska viipaleiden enimmäismääräksi on asetettu 2, kahden pyynnön tulosten liitto vastaa rullakyselyn tuloksia ilman viipalointia.

oletuksena jako tehdään ensin sirpaleille ja sitten paikallisesti jokaiselle sirpaleelle käyttäen _uid-kenttää seuraavalla kaavalla:

slice(doc) = floorMod(hashCode(doc._uid), max)

suorituskykyyn liittyvät näkökohdat:

Vieritysrajapinta : Tausta yhdistää prosessi optimoi indeksin yhdistämällä pienempiä segmenttejä luoda uusia suurempia segmenttejä, jolloin pienemmät segmentit poistetaan. Tämä prosessi jatkuu vierityksen aikana, mutta avoin hakuyhteys estää vanhojen segmenttien poistamisen, kun ne ovat vielä käytössä. Näin Elasticsearch pystyy palauttamaan alkuperäisen hakupyynnön tulokset riippumatta myöhemmistä asiakirjoihin tehdyistä muutoksista.

vanhempien segmenttien pitäminen elossa tarkoittaa, että tarvitaan lisää tiedostokahvoja. Varmista, että solmut on määritetty on runsaasti vapaa tiedosto käsittelee ja selaa API-kontekstin tyhjennetään pian tietojen noudon jälkeen.

voimme tarkistaa kuinka monta hakuyhteyttä on avoinna solmujen stats API: lla:

curl -XGET 'ES_HOST:ES_PORT/_nodes/stats/indices/search?pretty'

näin ollen on erittäin tarpeen tyhjentää Selaa API kontekstissa kuvattu aiemmin Clear Selaa API osiossa.

Sliced Scroll API : Jos viipaleiden määrä on suurempi kuin sirpaleiden määrä viipalesuodatin on hyvin hidas ensimmäisillä puheluilla, sen monimutkaisuus on O(N) ja muistikustannus on yhtä suuri kuin n bittiä viipaletta kohti, jossa N on sirpaleessa olevien asiakirjojen kokonaismäärä. Muutaman puhelun jälkeen suodatin on välimuistissa ja myöhempien puhelujen pitäisi olla nopeampia, mutta sinun pitäisi rajoittaa viipaloidun kyselyn määrää, jonka suoritat rinnakkain, jotta muisti ei räjähdä.

Huomautus: viipaleiden enimmäismäärä kääröä kohti on rajoitettu 1024: ään, ja se voidaan päivittää käyttämällä index.max_slices_per_scroll – indeksiasetusta tämän rajan ohittamiseksi.

näiden kustannusten välttämiseksi kokonaan on mahdollista käyttää toisen kentän doc_values viipalointia varten, mutta käyttäjän on varmistettava, että kentällä on seuraavat ominaisuudet:

  • kenttä on numeerinen.
  • doc_values ovat käytössä kyseisessä kentässä
  • jokaisen asiakirjan tulee sisältää yksi arvo. Jos asiakirjassa on useita arvoja määritetylle kentälle, käytetään ensimmäistä arvoa.
  • kunkin asiakirjan arvo on asetettava kerran, kun asiakirja on luotu eikä sitä ole koskaan päivitetty. Näin varmistetaan, että jokainen viipale saa deterministisiä tuloksia.
  • kentän kardinaalisuuden tulisi olla korkea. Näin varmistetaan, että jokainen siivu saa suunnilleen saman määrän asiakirjoja.

kenttä “päivämäärä” palvelee luontaisesti ominaisuuksia edellä, joten sitä voidaan käyttää viipalointiin:

curl -XGET 'ES_HOST:ES_PORT/twitter-*/tweet/_search?scroll=1m&pretty' -H 'Content-Type: application/json' -d '{ "slice": { "field": "date", "id": 0, "max": 10 }, "query": { "match" : { "text" : "elasticsearch" } }}'

kokeile Qbox isännöi Elasticsearch

se on helppo spin ylös standardin isännöi Elasticsearch cluster tahansa 47 Rackspace, Softlayer, tai Amazon datakeskukset. Ja voit nyt tarjota omia AWS krediittejä Qbox Private Hosted Elasticsearch.

kysymyksiä? Jätä viesti, niin saat nopean vastauksen.

ei vielä nauti isännöidyn ELK-stack enterprise-haun eduista qboxissa? Kutsumme sinut luomaan tilin tänään ja selvittää, kuinka helppoa on hallita ja skaalata Elasticsearch ympäristö pilvipalvelussamme.

Vastaa

Sähköpostiosoitettasi ei julkaista.