7,540
edits
Changes
→Alap műveletek
</pre>
==Join statement==
===Áttekintés===
Lehetőség van rá hogy egyfajta relációt vezessünk be egy indexben lévő dokumentumok között, egy szülő-gyerek kapcsolatot. A relációt típusát előre definiálni kell az index létrehozása közben úgy hogy előre megadjuk hogy milyen típusú dokumentumok állnak itt relációban egymással és meg kell adni egy mezőt is ami mind a két dokumentum típusban szerepelni fog mint a join mező. A szülő esetében a join mező csak hivatkozik a típusra, amit az index létrehozása közben definiáltuk, míg a gyerekél egyrészt hivatkozik a típusra, másrészt a szülő ID-jára is.
A joint kapcsolatot nem szabad relációs adatbázis kapcsolatként használni. Csak akkor szabad használni ha a gyerek elemek lényegesen többen vannak mint a szülő elem, különben nagyon rossz lesz a performancia. Fontos megkötések vannak a join-ak kapcsolatban amitől egy kicsit úgy is tűnik, hogy nem igazán kiforrott ez még:
* Egy indexen belül csak egy darab join mapping definíció lehet
* A szülés és a gyerek muszáj hogy ugyan abban a shard-ban legyen, erre nekünk kell figyelni a létrehozás közben.
* Egy elemnek csak egy szülője lehet, de bármennyi gyereke.
===Használat===
Az alábbi példában létrehozzuk a '''mycompany''' nevű index-et, miben definiálunk egy relációt, ahol azt mondjuk meg, hogy a '''question''' a szülője az answer-nek. Ezek it nem szigorú értelembe vett dokumentum típusok, tehát nem kell hogy ''mycompany/question'' ill ''mycomapany/answer'' -be hozzuk őket létre. Ezek sokkal inkább egyfajta címkék, amiket majd rá kell aggatni a szülőre ill a gyerekre. Lényeg, hogy mikor majd létrehozzuk a szülő dokumentumot, akkor abban lennie kell majd egy '''my_join_field''' nevű mezőnek, aminek az értéke vagy question vagy és a gyerek dokumentumban pedig szintén lennie kell majd egy '''my_join_field''' nevű mezőnek aminek az értéke '''answer'''.
<pre>
curl -XPUT "192.168.123.71:9200/mycompany" -H 'Content-Type: application/json' -d'
{
"mappings": {
"_doc": {
"properties": {
"my_join_field": {
"type": "join",
"relations": {
"question": "answer"
}
}
}
}
}
}
'
</pre>
Adjunk hozzá egy szülő dokumentumot:
<pre>
curl -X PUT "192.168.123.71:9200/mycompany/_doc/2?refresh" -H 'Content-Type: application/json' -d'
{
"text": "This is another question",
"my_join_field": "question"
}
'
</pre>
Majd két gyerek objektumot. Mivel megkötés, hogy ugyan abba a shar-ba kell kerüljön mint a szülő, ezért ezt nekünk külön kézzel ki kell kényszeríteni. A szülő létrehozásakor nem adtunk meg routing id-t, így ahogy azt már korábban láthattuk, a shard meghatározásához a dokumentum ID-t használta fel az Elasticsearch, ami az '''1''' volt. Ha nem adnánk most itt meg routing ID-t, akkor a '''3'''-as és '''4'''-es ID-t használná fel az Elasticsearch (ami itt a két dokumentum ID), ami isten tudja melyik shard-ba esne. Ezért itt külön meg kell adni a '''routing''' paraméterrel az 1-es ID-t.
<pre>
curl -XPUT "192.168.123.71:9200/mycompany/_doc/3?routing=1&refresh&pretty" -H 'Content-Type: application/json' -d'
{
"text": "This is an answer",
"my_join_field": {
"name": "answer",
"parent": "1"
}
}
'
curl -XPUT "192.168.123.71:9200/mycompany/_doc/4?routing=1&refresh&pretty" -H 'Content-Type: application/json' -d'
{
"text": "This is an other answer",
"my_join_field": {
"name": "answer",
"parent": "1"
}
}
'
</pre>
A relációk megjelennek a dokumentumokon, ha lekérdezzük őket. A lekérdezéshez nagyon hasznos lesz a '''children aggregation''' (lásd lentebb)
<br>
==Bulk műveletek==
