Odwzorowania zależności Elasticsearch (jeden do jednego i jeden do wielu)

Question

Odwzorowania zależności Elasticsearch (jeden do jednego i jeden do wielu)

W moim elastycznym serwerze wyszukiwania mam jeden indeks http://localhost:9200/blog.
Indeks (blog) zawiera wiele typów.

E. g.: http://localhost:9200/blog/posts, http://localhost:9200/blog/tags.

W typie tagów utworzyłem ponad 1000 tagów i 10 postów utworzonych w typie postów.

Np.: posty

{   
    "_index":"blog",
    "_type":"posts",
    "_id":"1",
    "_version":3,
    "found":true,
    "_source" : {
        "catalogId" : "1",
       "name" : "cricket",
       "url" : "http://www.wikipedia/cricket"
    }
}

Np.: tagi

{   
    "_index":"blog",
    "_type":"tags",
    "_id":"1",
    "_version":3,
    "found":true,
    "_source" : {
        "tagId" : "1",
        "name" : "game"
    }
}

Chcę przypisać istniejący tag do postów na blogu (np. relation => mapping).

Jak przypisać tagi do mapowania postów?

20

mapping elasticsearch relationship elastica

Author: Mike Rylander, 2014-05-01

Source

1 answers

score 45 · Accepted Answer

Istnieją 4 podejścia, które można wykorzystać w Elasticsearch do zarządzania relacjami. Są one bardzo dobrze opisane w blogu Elasticsearch post- Zarządzanie relacjami w Elasticsearch polecam przeczytać cały artykuł, aby uzyskać więcej szczegółów na temat każdego podejścia, a następnie wybrać to podejście, które najlepiej spełnia Twoje potrzeby biznesowe, pozostając technicznie odpowiednim.

Oto najważniejsze dla 4 podejść.

Inner Obiekt

łatwy, szybki, wydajny

ma zastosowanie tylko wtedy, gdy utrzymywane są relacje jeden do jednego

brak potrzeby specjalnych zapytań

Zagnieżdżone

zagnieżdżone dokumenty są przechowywane w tym samym bloku Lucene co każdy inny, co ułatwia odczyt / wykonywanie zapytań. Odczyt zagnieżdżonego dokumentu jest szybszy niż równoważny rodzic/dziecko.

Aktualizacja pojedynczego pola w zagnieżdżonym dokumencie (rodzicu lub zagnieżdżonym dziecku) wymusza ES reindex całego zagnieżdżonego dokumentu. Może to być bardzo kosztowne w przypadku dużych zagnieżdżonych dokumentów

"porównywanie" zagnieżdżonych dokumentów jest niemożliwe

najlepiej nadaje się do danych, które nie zmieniają się często

Rodzic / Dziecko

dzieci są przechowywane oddzielnie od rodzica, ale są kierowane do tego samego odłamka. Tak więc rodzic / dzieci mają nieco mniejszą wydajność przy odczycie / zapytaniu niż zagnieżdżone

mapowanie rodzica/dziecka ma trochę więcej pamięć overhead, ponieważ ES utrzymuje listę "join" w pamięci

Aktualizacja dokumentu podrzędnego nie wpływa na rodzica ani żadne inne dzieci, co może potencjalnie zaoszczędzić wiele indeksowania w dużych dokumentach [13]}

sortowanie / punktowanie może być trudne dla rodzica / dziecka, ponieważ operacje Has Child / Has Parent mogą być czasami nieprzezroczyste

Denormalizacja

Możesz zarządzać wszystkimi relacjami sam!
najbardziej elastyczny, najbardziej administracyjny overhead

może być mniej lub bardziej wydajny w zależności od konfiguracji