ElasticSearch: Wpływ ustawienia pola "not_analyzed" na "store": "yes"?

Question

Załóżmy, że w polu mapowania jest określone pole łańcuchowe określone jako not_analyzed. Jeśli następnie dodaję do mapowania "store":"yes", czy ElasticSearch będzie duplikować pamięć masową? Moje rozumienie pól not_analyzed polega na tym, że nie są one przeprowadzane przez analizator indeksowany , podobnie jak, ale klient jest w stanie dopasować się do niego. Tak więc, jeśli pole jest zarówno not_analyzed i store:yes, może to spowodować, że ElasticSearch będzie przechowywać dwie kopie ciągu.

Moje pytanie:

• Jeśli pole ciąg jest przechowywany zarówno not_analyzed i store:yes, tam będzie duplikat przechowywanie ciąg?

Mam nadzieję, że to wystarczająco jasne. Dzięki!

Answer 1

Miksujesz pojęcie indeksowanego pola i zapisanego pola w lucene, bibliotece, na której zbudowano elastyczne wyszukiwanie.

Pole jest indeksowane, gdy przechodzi w indeks odwrócony, struktura danych używana przez lucene w celu zapewnienia jej doskonałych i szybkich możliwości wyszukiwania pełnotekstowego. Jeśli chcesz szukać na polu, musisz go zaindeksować. Podczas indeksowania pola możesz zdecydować, czy chcesz go zaindeksować tak, jak jest, czy też chcesz go przeanalizować, co oznacza podjęcie decyzji o zastosowaniu tokenarza, który wygeneruje listę tokenów (słów) i listę tokena filtry, które mogą modyfikować wygenerowane tokeny (nawet dodawać lub usuwać niektóre). Sposób indeksowania pola wpływa na sposób wyszukiwania. Jeśli indeksujesz pole, ale go nie analizujesz, a jego tekst składa się z wielu słów, będziesz mógł znaleźć ten dokument tylko w poszukiwaniu tego konkretnego tekstu, włącznie z spacji.

Pole jest przechowywane, jeśli chcesz je odzyskać. Powiedzmy, że Lucene zapewnia również pewien rodzaj przestrzeni dyskowej, która nie ma nic wspólnego z samym odwróconym indeksem. Podczas wyszukiwania z użyciem lucenu uzyskuje się listę zgodnych identyfikatorów dokumentów. Następnie możesz pobrać tekst ze swoich zapisanych pól, co jest dosłownie pokazywane jako wyniki wyszukiwania. Jeśli nie przechowujesz pola, nigdy nie będziesz w stanie go odzyskać z lucenu (nie jest to prawdą w przypadku elastycznego wyszukiwania, jak to wyjaśnię poniżej).

Możesz mieć pola, które chcesz przeszukiwać, i nigdy nie pokazywać: indeksowane i niezapisane (domyślnie w Lucinie).
Możesz mieć pola, które chcesz wyszukać, a także pobrać: zindeksowane i zapisane.
Możesz mieć pola, których nie chcesz wyszukiwać, ale chcesz je odzyskać, aby je wyświetlić.

Dlatego obie struktury danych nie są ze sobą powiązane. Jeśli zarówno indeksujesz, jak i przechowujesz pole w lucene, jego zawartość nie będzie występować dwa razy w tej samej formie. Przechowywane pola są przechowywane w takiej postaci, w jakiej zostały wysłane, do lucenu, podczas gdy indeksowane pola mogą być analizowane i będą częścią odwróconego indeksu, czyli czymś innym. Przechowywane pola są pobierane do określonego dokumentu (według lucen document id), podczas gdy indeksowane pola są wyszukiwane, w takiej strukturze, która dosłownie odwraca tekst, co powoduje, że każdy termin jest kluczem, wraz z listą dokumentów Identyfikatory, które go zawierają (lista księgowań).

Jeśli chodzi o elastyczne wyszukiwanie, niektóre rzeczy nieznacznie się zmieniają. Jeśli nie skonfigurujesz pola jako zapisanego w mapowaniu (domyślnie jest to store:no), domyślnie możesz je odzyskać.Dzieje się tak, ponieważ funkcja elasticsearch zawsze zapisuje w Lucu cały dokument źródłowy, który do niego wysyłasz (chyba że wyłączysz tę funkcję) w specjalnym polu luceńskim o nazwie _source.

Podczas wyszukiwania przy użyciu elastycznego wyszukiwania domyślnie otrzymujesz całe pole źródłowe, ale możesz także poprosić o konkretne pola. W takim przypadku elasticsearch sprawdza, czy te konkretne pola są przechowywane w lucene. Jeśli są one treścią, zostaną pobrane z lucenu, w przeciwnym razie przechowywane pole zostanie odczytane z lucenu, przeanalizowane jako json (analiza parsowania) i te specyficzne pola zostaną wyodrębnione. W pierwszym przypadku może być trochę szybszy, ale niekoniecznie. Jeśli twoje źródło jest naprawdę duże i chcesz załadować tylko kilka pól, skonfigurowanie ich jako zapisanych w lucene prawdopodobnie przyspieszy proces ładowania; z drugiej strony, jeśli twoje _source nie jest tak duże i chcesz załadować wiele pól, to prawdopodobnie lepiej będzie załadować tylko jedno zapisane pole (_source), które będzie prowadzić do pojedynczego wyszukiwania dysku, analizowania go itp. W większości przypadków przy użyciu pola _source działa dobrze.

Aby odpowiedzieć na pytanie: odwrócony indeks i pamięć lucenu to dwie zupełnie różne rzeczy. W efekcie masz dwie kopie tych samych danych w lucene tylko wtedy, gdy zdecydujesz się zapisać pole (store:yes w odwzorowaniu), ponieważ elasticsearch zachowuje tę samą treść w jsonie _source, ale to nie ma nic wspólnego z faktem że indeksujesz lub analizujesz pole.