Simoni Hay

w tym poście będziemy używać hosted Elasticsearch na Qbox.io. możesz zarejestrować się lub uruchomić klaster tutaj lub kliknąć “Rozpocznij” w nawigacji w nagłówku. Jeśli potrzebujesz pomocy w konfigurowaniu, zapoznaj się z tematem “udostępnianie klastra Qbox Elasticsearch.”

zalety, jakie rodzic-dziecko ma nad zagnieżdżonymi obiektami, są następujące:

• dokument nadrzędny można aktualizować bez ponownego wprowadzania dzieci.
• dokumenty potomne można dodawać, zmieniać lub usuwać bez wpływu na rodzica lub inne dzieci. Jest to szczególnie przydatne, gdy dokumenty potomne są duże i wymagają częstego dodawania lub zmiany.
• dokumenty potomne mogą być zwracane jako wyniki żądania wyszukiwania.

relacja rodzic-dziecko ma charakter podobny do modelu zagnieżdżonego: oba pozwalają nam powiązać jedną jednostkę z inną. Różnica polega na tym, że w przypadku obiektów zagnieżdżonych wszystkie elementy znajdują się w tym samym dokumencie, podczas gdy w przypadku rodzic-dziecko rodzic i dzieci są całkowicie oddzielnymi dokumentami. Jednak jest również związany z pewnymi ograniczeniami:

ograniczenia rodzic – dziecko

• typy rodzic i dziecko muszą być różne lub nie można ustanowić relacji rodzic-dziecko między dokumentami tego samego typu.
• ustawienie _parent.type może wskazywać tylko typ, który jeszcze nie istnieje. Oznacza to, że typ nie może stać się typem nadrzędnym po jego utworzeniu.
• dokumenty rodzica i dziecka muszą być indeksowane na tym samym Odłamku. Identyfikator rodzica jest używany jako wartość routingu dla potomka, aby upewnić się, że potomek jest indeksowany w tym samym Odłamku co rodzic. Oznacza to, że przy pobieraniu, usuwaniu lub aktualizowaniu dokumentu podrzędnego należy podać tę samą wartość nadrzędną.

główne różnice między relacjami rodzic-dziecko i zagnieżdżone można podsumować w następujący sposób:

zagnieżdżony obiekt	rodzic-dziecko
1. Zagnieżdżone obiekty są zapisywane w tym samym dokumencie.	Obiekty nadrzędne i podrzędne są zapisywane oddzielnie w różnych dokumentach.
2. Obiekt potomny może mieć wiele obiektów nadrzędnych.	obiekt potomny nie może mieć wielu obiektów nadrzędnych.
3. Zapytania są stosunkowo szybkie.	zapytanie jest powolne, ponieważ dziecko i rodzic są przechowywane oddzielnie.
4. Może łatwo utrzymać wiele zagnieżdżonych poziomów.	trudno utrzymać wiele zagnieżdżonych poziomów.
5. Zapytania poziomu zagnieżdżonego są dobrze zdefiniowane i proste w użyciu dla dowolnej liczby zagnieżdżonych obiektów. Również łańcuch zapytania może być użyty do odpytywania zagnieżdżonych obiektów.	zapytania komplikują się, gdy istnieje wiele relacji rodzic-dziecko.
6. Może pobrać wszystkie dane, ponieważ znajdują się one w tym samym obiekcie.	nie może pobrać zarówno dokumentów potomnych, jak i nadrzędnych w jednym zapytaniu.
7. Zagnieżdżony obiekt jest duplikowany dla każdego obiektu nadrzędnego.	nie ma powielania danych, ponieważ związek jest znormalizowany.
8. Jeśli zagnieżdżony obiekt zostanie zmieniony, wszystkie obiekty nadrzędne muszą zostać ponownie zindeksowane.	nie ma potrzeby ponownego indeksowania rodzica, ponieważ utrzymywane jest tylko połączenie między nimi.

zagnieżdżone obiekty mogą być preferowane w stosunku do rodzica-dziecka w celu obsługi asocjacji z następujących powodów:

• gdy modele baz danych zawierają wiele zagnieżdżonych skojarzeń na wielu poziomach. Dlatego można je łatwo obsługiwać za pomocą podejścia zagnieżdżonego obiektu.
• w podejściu rodzic-dziecko obiekt potomny nie może mieć wielu obiektów nadrzędnych.
• zagnieżdżone zapytania są łatwiejsze do wykonania w podejściu zagnieżdżonych obiektów.
• nie można pobrać zarówno pól potomnych, jak i nadrzędnych w jednym zapytaniu.

względy wydajności: Globalne porządki

globalne porządki to struktura danych na górze fielddata i doc values, która utrzymuje przyrostową numerację dla każdego unikalnego terminu w porządku leksykograficznym. Każdy wyraz ma unikalną liczbę, a liczba wyrazów A jest niższa niż liczba wyrazów B. Globalne porządki są obsługiwane tylko dla pól tekstowych i słów kluczowych.

wartości Fielddata i doc mają również ordinals, które są unikalną numeracją dla wszystkich terminów w danym segmencie i polu. Globalne porządki porządkowe opierają się na tym, zapewniając mapowanie między porządkami segmentowymi i globalnymi porządkami, te ostatnie są unikalne w całym Odłamku.

globalne porządki są używane dla funkcji, które używają porządków segmentów, takich jak sortowanie i agregacja terminów, w celu poprawy czasu wykonania. Agregacja terminów opiera się wyłącznie na globalnych porządkach, aby przeprowadzić agregację na poziomie odłamków, a następnie konwertuje globalne porządki na rzeczywisty termin tylko dla końcowej fazy redukcji, która łączy wyniki z różnych odłamków.

interesuje Cię Kubernetes? Sprawdź nasze wsparcie Kubernetes dla przedsiębiorstw

rodzic-dziecko używa globalnych porządków, aby przyspieszyć łączenie. Globalne ordinary muszą zostać odbudowane po każdej zmianie NA odłamek. Im więcej wartości ID rodzica jest przechowywanych w Odłamku, tym dłużej trwa odbudowa globalnych porządków dla pola _parent.

globalne porządki są domyślnie budowane chętnie: jeśli indeks się zmienił, globalne porządki dla pola _parent zostaną przebudowane jako część pola refresh. Może to dodać znaczny czas odświeżania. Jednak w większości przypadków jest to właściwy kompromis, w przeciwnym razie globalne porządki są przebudowywane, gdy używane jest pierwsze zapytanie rodzic-dziecko lub agregacja. Może to spowodować znaczny skok opóźnień dla użytkowników i zwykle jest to gorsze, ponieważ wiele globalnych porządków dla pola _parent może zostać odbudowanych w jednym interwale odświeżania, gdy ma miejsce wiele zapisów.

gdy rodzic / dziecko jest używane rzadko i zapisy występują często, może sensowne jest wyłączenie chętnego ładowania:

ilość stosu używanego przez globalne porządki można sprawdzić w następujący sposób:

wniosek

możliwość łączenia wielu pokoleń (jak Grandparents and Grandchildren) brzmi atrakcyjnie, dopóki nie pomyślisz o kosztach związanych z tym:

• im więcej dołączysz, tym gorsza będzie wydajność.
• każde pokolenie rodziców musi mieć swoje pola string _id zapisane w pamięci, która może zużywać dużo pamięci RAM.

rozważając swoje schematy relacji i czy rodzic-dziecko jest dla ciebie odpowiednie, rozważ tę radę dotyczącą relacji rodzic-dziecko:

• stosuj relacje rodzic-dziecko oszczędnie i tylko wtedy, gdy jest o wiele więcej dzieci niż rodziców.
• unikaj łączenia wielu rodziców z dziećmi w jednym zapytaniu.
• unikaj punktacji, używając filtra has_child lub zapytania has_child z ustawioną score_mode na brak.
• Zachowaj krótkie identyfikatory nadrzędne, aby lepiej kompresowały się w wartościach doc i zużywały mniej pamięci po przejściowym załadowaniu.

daj czadu!

łatwo jest uruchomić standardowy hostowany klaster Elasticsearch w dowolnym z naszych 47 centrów danych Rackspace, Softlayer lub Amazon. Możesz teraz udostępniać własne kredyty AWS na Qbox Private Hosted Elasticsearch.

masz pytania? Napisz do nas wiadomość, a otrzymasz szybką odpowiedź.

nie korzystasz jeszcze z zalet hostowanego wyszukiwania dla firm ELK-stack na Qbox? Zapraszamy do założenia konta już dziś i odkrycia, jak łatwo jest zarządzać i skalować środowisko Elasticsearch w naszej usłudze hostingu w chmurze.