Znaczące terminy powodują CircuitBreakingException

Question

Mam średniej wielkości indeks elasticsearch (1,46T lub ~ 1e8 dokumentów). Działa na 4 serwerach, z których każdy ma 64 GB pamięci RAM podzielony równomiernie między elastyczną a OS (dla buforowania).

Chcę wypróbować nową „Significant Określenia” agregacji więc wystrzelone następujące zapytanie ...

{ 
    "query": { 
    "ids": { 
     "type": "document", 
     "values": [ 
     "xCN4T1ABZRSj6lsB3p2IMTffv9-4ztzn1R11P_NwTTc" 
     ] 
    } 
    }, 
    "aggregations": { 
    "Keywords": { 
     "significant_terms": { 
     "field": "Body" 
     } 
    } 
    }, 
    "size": 0 
} 

Który powinien porównać ciało dokumentu określonego z resztą indeksie i znaleźć terminy znaczące dla dokumentu, które nie są powszechne w indeksie.

Niestety, niezmiennie skutkuje

ElasticsearchException [org.elasticsearch.common.breaker.CircuitBreakingException: dane zbyt duża, dane powinny być większa niż granica [25741911654] bajtów];

zagnieżdżone: UncheckedExecutionException [org.elasticsearch.common.breaker.CircuitBreakingException: dane zbyt duże, dane byłyby większe niż limit [25741911654] bajtów];

zagnieżdżone: CircuitBreakingException [Dane za duże, dane będą większe niż limit [25741911654] bajtów];

po minucie lub dwóch i wydaje się sugerować, że mam za mało pamięci.

Elastyczne serwery, o których mowa, są w rzeczywistości maszynami wirtualnymi, więc zamknąłem inne maszyny wirtualne i nadałem każdej elastycznej instancji 96 GB i każdemu z systemów kolejne 96 GB.

Wystąpił ten sam problem (inne numery trwały dłużej). Nie mam sprzętu do ręki z ponad 192 GB dostępnej pamięci, więc nie mogę iść wyżej.

Czy agregacje nie są przeznaczone do użycia z indeksem jako całością? Czy popełniam błąd w odniesieniu do formatu zapytania?

Answer 1

W dokumentacji tej agregacji znajduje się ostrzeżenie dotyczące użycia pamięci RAM w polach tekstowych dla bardzo dużych indeksów [1]. W przypadku dużych indeksów działa dobrze w przypadku pól o mniejszej liczności z mniejszym słownictwem (np. Hashtagów), ale kombinacja wielu haseł tekstowych i wielu dokumentów to pamięć-świnia. Można przyjrzeć się określeniu filtru dotyczącego ładowania pamięci podręcznej FieldData [2] dla pola Body w celu przycięcia długiego ogona terminów o niskiej częstotliwości (np. Doc częstotliwość < 2), co zmniejszy koszty ogólne pamięci RAM.

Użyłem odmiany tego algorytmu przedtem, w którym tylko próbka najlepiej pasujących dokumentów została przeanalizowana pod kątem istotnych terminów i to podejście wymaga mniej pamięci RAM, ponieważ tylko najlepsze dokumenty N są odczytywane z dysku i tokenizowane (za pomocą TermVectors lub analizator). Jednak na razie implementacja w Elasticsearch opiera się na pamięci podręcznej FieldData i wyszukuje terminy dla WSZYSTKICH zgodnych dokumentów.

Jeszcze jedno - gdy mówisz, że chcesz "porównać treść dokumentu określonego", zwróć uwagę, że zwykłym trybem działania jest porównywanie zestawu dokumentów z tłem, a nie tylko jeden. Cała analiza opiera się na liczbie częstotliwości dokumentów, więc przy próbie zestawu tylko jednego dokumentu wszystkie terminy będą miały częstotliwość pierwszego planu równą 1, co oznacza, że ​​masz mniej dowodów, aby wzmocnić dowolną analizę.