db.dobo.sk

quick reference

1. Zalozeny na Apache Lucene, ktoru pouziva ako libku. Tu obaluje vlastnou logikou. Inak napisany v Jave
2. Pristup bud cez javoveho klienta (port 9300), castejsie vsak cez RestAPI via http/https (port 9200)
3. Data to storuje ako dokumenty a indexuje v JSON
4. Prostrednictvom RestAPI sa pouzivaju klasicke metody GET, PUT, DELETE, HEAD
5. Storovanie dat do Elasticu sa nazyva indexovanie (indexing), kazdy index je vlastne domena dat. Hierarchia je nasledovna: index – type – document – atributy (pole dokumentu)
6. Index je nieco podobne, ako klasicke indexy v SQL databazach, az na to, ze Elastic pouziva inverted index.
7. Vytahovanie a dotazovanie dat je mozne viacerymi sposobmi: Lite, DSL, full-text, phrase-search etc…
8. Zatialco index je vlastne len namespace, data su skutocne ulozene v shardoch (datove kontajnery). Shard je jedna plnohodnotna instancia Lucene, aplikacia vsak nikdy nekomunikuje priamo so shardom, ale s indexom. Shardy su primarne a repliky. Pocet primarnych shardov v indexe je pevne dany (defaultne je to pri vytvarani indexu 5), ked sa vytvara index, ale replik moze byt habakuk. Elastic ich presuva po nodoch v ramci clusteru. Podjednotkou shardov su segmenty, ktore obsahuju dokumenty.
9. Elastic je clusterova zalezitost, sice moze byt len jeden node, ale standardne sa redundancia a loadbalancing realizuje tym, ze cluster (horizontalne skalovanie). User sa moze doptavat akehokolvek nodu a vsetky nody maju informacie, kde sa nachadza doptavany dokument.
10. Jeden node je vzdycky master (vacsinou prvy instalovany) a pokial zdochne, tak Elastic vytvori master z dalsieho nodu. To iste sa tyka shardov – pokial napr. chcipne node s primarnym shardom, tak sa vytvori z repliky novy primarny shard. Kazdy node je z principu kontrol node (sam si kontroluje flow dat), ale nemusi storovat data. Mozu byt dedikovane data nody a kontrol nody (pokial nestoruju data, sluzia vlastne ako loadbalancery).
11. Elastic nema ACID concurrency control, ako transakcne SLQ databaze. Pouziva “optimisticky concerrency control” – predpoklada, ze v priebehu editacie/retrievovania dokumentu nikto iny dokument nemeni. Da sa to ciastocne obchadzat parametrom _version, co je inkrementalne cislo verzie dokumentu – v pripad ekonfliktu vyhrava vyssie cislo.
12. Vnutorna logika toho, do ktoreho shardu sa uklada dokument (a z kroreho bude retrievovany), sa nazyva routing. Je definovany formulou shard = hash(document id) / number_of_shards. Z tohto dovodu je vidiet, preco musi byt pocet shardov pr eindex konstantny od vytvorenia indexu.
13. S dokumentnmi v Elasticu sa pracuje cez API: index, get, delete, bulk, mget, update

7. Searching, filtering, sorting

curl -X GET “localhost:9200/_search?pretty” – “prazdne vyhladavanie” bez filtrov, vylistuje vsetky hity vo vsetkych indexoch; standardne uvedie took – cas (v milisekundach) potrebny na spracovanie dotazu a shard – pocet shardov, ktore boli dotazane. Tento dotaz je prikladom tzv. Lite dotazovania cez API, v praxi sa to moc nepouziva.

Bodysearch DSL je vyuzitim castejsej metody, kedy sa to posiela do API cez HTTP obal. Bodysearch preto, pretoze dotaz je v tele JSONu:

curl -X GET “localhost:9200/_search?pretty” -H ‘Content-Type: application/json’ -d’
{
“query”: { }
}
‘

V zasade je najvacsi rozdiel medzi vyhladavanim podla nejakeho parametru (text, date, id…) a fultext search. Zatialco parameter je velmi podobny SQL databazam (v elasticu sa nazyva term search) a je z hladiska logiky jednoduchy, fultext je “inteligentny” a snazi sa vyhovovat dotazu nie booleovsky (je/nie je, zodpoveda/nezodpoveda), ale zoradit vysledky podla relevantnosti. Na to pouziva inverted index a hlavne analyzu dokumentu, ktora pozostava z tokenizacie a normalizacie. V ramci vytvarania typov dokumentu zaroven robi mapping (t.j. definici datatypu pre jednotlive polia dokumentu).

Pri fultexte zoraduje Elastic vysledky podla relevancie (_score flag), pricom zalezi na niekolkych parametroch, ako to vybera.

Bool query pouziva formulacie must, must_not, should a filter na pokrocie filtrovanie. Kazdopadne je to hladanie podla podla parametru (term search).

9. Administracia clusteru

curl -H 'Content-Type: application/json' -XGET https://localhost:9200/_cluster/health?pretty

– ukaze stav a kondiciu clusteru (farebne odlisene). Ukazuje stav indexov podla kondicie najhorsieho indexu

Niekedy je nutne vypnut node (maintenance a pod.). Ak sa to urobi ad-hoc, tak cluster zacne “presuvat” shardy – repliky na inom node zmeni na primary a inde vytvori nove repliky. Ak tomu chcem zamedzit (pretoze vypnuty node za chvilu zapnem), tak:

PUT /_cluster/settings
{
    "transient" : {
        "cluster.routing.allocation.enable" : "none"
    }
}

Analogicky potom zapnutie realokovania shardov:

PUT /_cluster/settings
{
    "transient" : {
        "cluster.routing.allocation.enable" : "all"
    }
}

OK, cluster je z principu trochu datalossproof, ale backup je backup. Nezavisle od ineho backupovacieho riesenia, ma Elastic vlastne instrumenty, co sa tyka backupu a to snapshoty clusteru via API. Je nutne mat nejaku external storage (NFS, S3 atd…):

POST _snapshot/my_backup/ 
{
    "type": "fs",
    "settings": {
        "location": "/mount/elastic_backups",
        "max_snapshot_bytes_per_sec" : "10mb", 
        "max_restore_bytes_per_sec" : "10mb"
    }
}

V tomto priklade sa okrem miesta pre backup definuju aj paremetre sietovej priepustnosti. Inak elasticove backupy su “mudre” a okrem prveho backupu potom zalohuju len deltu dat.