Elasticsearch
Różnica między indeksami i typami

Łatwo jest zobaczyć type takie jak tabela w bazie danych SQL, gdzie index jest baza danych SQL. Nie jest to jednak dobry sposób podejścia do type s.

Wszystkie typy

W rzeczywistości typy są dosłownie tylko polami metadanych dodawanymi do każdego dokumentu przez Elasticsearch: _type . Powyższe przykłady stworzyły dwa typy: my_type i my_other_type . Oznacza to, że każdy dokument powiązany z typami ma automatycznie zdefiniowane dodatkowe pole, takie jak "_type": "my_type" ; jest to indeksowane wraz z dokumentem, co czyni go polem przeszukiwalnym lub filtrowalnym , ale nie wpływa na sam surowy dokument, więc aplikacja nie musi się o to martwić.

Wszystkie typy żyją w tym samym indeksie, a zatem w tych samych zbiorczych fragmentach indeksu. Nawet na poziomie dysku znajdują się w tych samych plikach. Jedyne rozdzielenie, jakie zapewnia utworzenie drugiego typu, jest logiczne. Każdy typ, czy to unikalny, czy nie, musi istnieć w mapowaniach, a wszystkie te mapowania muszą istnieć w stanie klastra. To zużywa pamięć, a jeśli każdy typ jest dynamicznie aktualizowany, zwiększa wydajność wraz ze zmianą mapowań.

W związku z tym najlepszą praktyką jest definiowanie tylko jednego typu, chyba że faktycznie potrzebujesz innych typów. Często spotyka się scenariusze, w których pożądanych jest wiele typów. Na przykład wyobraź sobie, że masz indeks samochodu. Przydaje się podział na wiele typów:

• BMW
• pogoń
• Honda
• mazda
• mercedes
• Nissan
• rangerover
• Toyota
• ...

W ten sposób możesz wyszukać wszystkie samochody lub ograniczyć je według producenta na żądanie. Różnica między tymi dwoma wyszukiwaniami jest tak prosta, jak:

GET /cars/_search

i

GET /cars/bmw/_search

Dla nowych użytkowników Elasticsearch nie jest oczywiste, że druga forma jest specjalizacją pierwszej formy. Dosłownie zostaje przepisany na:

GET /cars/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "term" : {
            "_type": "bmw"
          }
        }
      ]
    }
  }
}

Po prostu odfiltrowuje każdy dokument, który nie został zindeksowany za pomocą pola _type którego wartość to bmw . Ponieważ każdy dokument jest indeksowany ze swoim typem jako pole _type , służy to jako dość prosty filtr. Jeśli w którymkolwiek z przykładów podano rzeczywiste wyszukiwanie, filtr zostałby odpowiednio dodany do pełnego wyszukiwania.

W związku z tym, jeśli typy są identyczne, o wiele lepiej jest podać jeden typ (np. manufacturer w tym przykładzie) i skutecznie go zignorować. Następnie w każdym dokumencie wyraźnie podaj pole o nazwie make lub dowolna nazwa i ręcznie filtruj je, gdy tylko chcesz. Zmniejszy to rozmiar twoich mapowań do 1/n gdzie n jest liczbą oddzielnych typów. Dodaje kolejne pole do każdego dokumentu na korzyść skądinąd uproszczonego mapowania.

W Elasticsearch 1.xi 2.x takie pole należy zdefiniować jako

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "string",
        "index": "not_analyzed"
      }
    }
  }
}

1. Nazwa jest dowolna.
2. Nazwa jest dowolna i może być zgodna z nazwą typu, jeśli jej również chcesz.

W Elasticsearch 5.x powyższe będzie nadal działać (jest przestarzałe), ale lepszym sposobem jest użycie:

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "keyword"
      }
    }
  }
}

1. Nazwa jest dowolna.
2. Nazwa jest dowolna i może być zgodna z nazwą typu, jeśli jej również chcesz.

Typy powinny być stosowane oszczędnie w obrębie indeksów, ponieważ nadymają odwzorowania indeksów, zwykle bez większych korzyści. Musisz mieć co najmniej jeden, ale nic nie mówi, że musisz mieć więcej niż jeden.

Często zadawane pytania

• Co jeśli mam dwa (lub więcej) typy, które są w większości identyczne, ale które mają kilka unikalnych pól dla każdego typu?

Na poziomie indeksu nie ma różnicy między jednym typem używanym z kilkoma rzadko używanymi polami a między wieloma typami, które współużytkują kilka nierzadkich pól z kilkoma nieudostępnionymi (co oznacza, że drugi typ nigdy nie używa pola (s)).

Inaczej mówiąc: rzadko używane pole jest rzadkie w całym indeksie, niezależnie od typów . Rzadkość nie korzysta - ani nie szkodzi - indeksowi tylko dlatego, że jest zdefiniowany w osobnym typie.

Powinieneś po prostu połączyć te typy i dodać osobne pole typu.

• Dlaczego osobne typy muszą definiować pola dokładnie w ten sam sposób?

Ponieważ każde pole jest tak naprawdę zdefiniowane tylko raz na poziomie Lucene, bez względu na liczbę typów. Fakt, że typy w ogóle istnieją, jest cechą Elasticsearch i jest tylko logiczną separacją.

• Czy mogę zdefiniować osobne typy z tym samym polem zdefiniowanym inaczej?

Nie. Jeśli uda ci się znaleźć sposób na wykonanie tego w ES 2.x lub nowszej, powinieneś otworzyć raport o błędzie . Jak zauważono w poprzednim pytaniu, Lucene traktuje je wszystkie jako jedno pole, więc nie ma sposobu, aby działało to odpowiednio.

ES 1.x pozostawił to jako domniemane wymaganie, które pozwoliło użytkownikom stworzyć warunki, w których odwzorowania jednego fragmentu w indeksie faktycznie różniły się od innego fragmentu w tym samym indeksie. To był w rzeczywistości wyścig i może prowadzić do nieoczekiwanych problemów.

Wyjątki od reguły

• Dokumenty nadrzędne / podrzędne wymagają stosowania oddzielnych typów w ramach tego samego indeksu.
  • Rodzic mieszka w jednym typie.
  • Dziecko żyje w osobnym typie (ale każde dziecko żyje w tym samym odłamku, co jego rodzic).
• Niezwykle niszowe przypadki użycia, w których tworzenie ton indeksów jest niepożądane, a wpływ rzadkich pól jest lepszy niż alternatywa.
  • Na przykład wtyczka monitorująca Elasticsearch, Marvel (1.x i 2.x) lub X-Pack Monitoring (5.x +), sam monitoruje Elasticsearch pod kątem zmian w klastrze, węzłach, indeksach, określonych indeksach (poziom indeksu), a nawet odłamki. Może tworzyć ponad 5 indeksów każdego dnia, aby wyodrębnić te dokumenty, które mają unikalne mapowania, lub może być sprzeczny z najlepszymi praktykami w celu zmniejszenia obciążenia klastra poprzez udostępnienie indeksu (uwaga: liczba zdefiniowanych mapowań jest faktycznie taka sama, ale liczba utworzonych indeksów jest zmniejszona z n do 1).
  • To jest zaawansowany scenariusz, ale musisz wziąć pod uwagę wspólne definicje pól dla różnych typów!