Elasticsearch 2.1: Okno wyników jest za duże (index.max_result_window)

Pobieramy informacje z Elasticsearch 2.1 i pozwalamy użytkownikowi przeglądać wyniki. Gdy użytkownik zażąda wysokiego numeru strony, otrzymamy następujący komunikat o błędzie:

Okno wyników jest zbyt duże, rozmiar od + musi być mniejszy lub równy: [10000], ale był [10020]. Zobacz przewijany interfejs API, aby uzyskać bardziej efektywny sposób żądania dużych zestawów danych. Limit ten można ustawić, zmieniając parametr poziomu indeksu [index.max_result_window]

Elastyczna dokumentacja mówi, że dzieje się tak z powodu dużego zużycia pamięci i korzystania z przewijanego interfejsu API:

Wartości wyższe niż mogą zużywać znaczące fragmenty pamięci sterty na wyszukiwanie i na fragment wykonujący wyszukiwanie. Najbezpieczniej jest pozostawić tę wartość, ponieważ jest to użycie interfejsu API przewijania do dowolnego głębokiego przewijania https://www.elastic.co/guide/en/elasticsearch/reference/2.x/breaking_21_search_changes.html#_from_size_limits

Chodzi o to, że nie chcę pobierać dużych zestawów danych. Chcę tylko pobrać wycinek ze zbioru danych, który jest bardzo wysoko w zestawie wyników. Również przewijany dokument mówi:

Przewijanie nie jest przeznaczone dla żądań użytkowników w czasie rzeczywistym https://www.elastic.co/guide/en/elasticsearch/reference/2.2/search-request-scroll.html

Pozostaje mi kilka pytań:

1) Czy zużycie pamięci byłoby naprawdę niższe (jeśli tak, dlaczego), gdybym użyłby przewijanego interfejsu API do przewijania w górę do wyniku 10020 (i zignorował wszystko poniżej 10000) zamiast wykonywać „normalne” żądanie wyszukiwania wyniku 10000-10020?

2) Nie wygląda na to, że scrolling API jest dla mnie opcją, ale muszę zwiększyć "index.max_result_window". Czy ktoś ma z tym jakieś doświadczenie?

3) Czy są jakieś inne możliwości rozwiązania mojego problemu?

Jeśli potrzebujesz głębokiej paginacji, jednym z możliwych rozwiązań jest zwiększenie wartości max_result_window. Możesz curlto zrobić z linii poleceń powłoki:

curl -XPUT "http://localhost:9200/my_index/_settings" -H 'Content-Type: application/json' -d '{ "index" : { "max_result_window" : 500000 } }'

Nie zauważyłem zwiększonego użycia pamięci, dla wartości ~ 100k.

Właściwym rozwiązaniem byłoby użycie przewijania.
Jeśli jednak chcesz przedłużyć wynikisearch zwroty powyżej 10000 wyników, możesz to łatwo zrobić z Kibana:

Przejdź do Dev Toolsi po prostu opublikuj poniższy kod w swoim indeksie (twoja_nazwa_indeksu), określając, jakie będzie nowe okno maksymalnych wyników

PUT your_index_name/_settings
{ 
  "max_result_window" : 500000 
}

Jeśli wszystko pójdzie dobrze, powinieneś zobaczyć następującą odpowiedź:

{
  "acknowledged": true
}

Poniższe strony w dokumentacji elastycznej mówią o głębokim stronicowaniu:

https://www.elastic.co/guide/en/elasticsearch/guide/current/pagination.html https://www.elastic.co/guide/en/elasticsearch/guide/current/_fetch_phase.html

W zależności od rozmiaru dokumentów, liczby fragmentów i używanego sprzętu, stronicowanie od 10 000 do 50 000 wyników (od 1 000 do 5 000 stron) powinno być całkowicie wykonalne. Ale przy wystarczająco dużych wartościach proces sortowania może być naprawdę bardzo ciężki, wykorzystując ogromne ilości procesora, pamięci i przepustowości. Z tego powodu zdecydowanie odradzamy głębokie stronicowanie.

Użyj interfejsu API Scroll, aby uzyskać ponad 10000 wyników.

Przykład przewijania w ElasticSearch NEST API

Użyłem tego w ten sposób:

private static Customer[] GetCustomers(IElasticClient elasticClient)
{
    var customers = new List<Customer>();
    var searchResult = elasticClient.Search<Customer>(s => s.Index(IndexAlias.ForCustomers())
                          .Size(10000).SearchType(SearchType.Scan).Scroll("1m"));

    do
    {
        var result = searchResult;
        searchResult = elasticClient.Scroll<Customer>("1m", result.ScrollId);
        customers.AddRange(searchResult.Documents);
    } while (searchResult.IsValid && searchResult.Documents.Any());

    return customers.ToArray();
}

Jeśli chcesz uzyskać więcej niż 10000 wyników, wówczas we wszystkich węzłach danych użycie pamięci będzie bardzo wysokie, ponieważ musi zwracać więcej wyników w każdym żądaniu zapytania. Jeśli masz więcej danych i więcej fragmentów, scalanie tych wyników będzie nieefektywne. Również buforuje kontekst filtru, stąd znowu więcej pamięci. Musisz próbować i popełniać błędy, ile dokładnie bierzesz. Jeśli otrzymujesz wiele żądań w małym oknie, powinieneś wykonać wiele zapytań dla więcej niż 10k i scalić je samodzielnie w kodzie, co ma zająć mniej pamięci aplikacji, niż jeśli zwiększysz rozmiar okna.

2) Nie wygląda na to, że scrolling API jest dla mnie opcją, ale muszę zwiększyć "index.max_result_window". Czy ktoś ma z tym jakieś doświadczenie?

-> Możesz zdefiniować tę wartość w szablonach indeksów, szablon es będzie miał zastosowanie tylko do nowych indeksów, więc musisz albo usunąć stare indeksy po utworzeniu szablonu, albo poczekać na pozyskanie nowych danych w elastynsearch.

{"order": 1, "template": "index_template *", "settings": {"index.number_of_replicas": "0", "index.number_of_shards": "1", "index.max_result_window": 2147483647},

W moim przypadku wygląda na to, że zmniejszenie wyników za pomocą prefiksów from & size do zapytania usunie błąd, ponieważ nie potrzebujemy wszystkich wyników:

GET widgets_development/_search
{
  "from" : 0, 
  "size": 5,
  "query": {
    "bool": {}
  },
  "sort": {
    "col_one": "asc"
  }
}