2014-07-25 8 views
5

Występują problemy z wydajnością podczas uruchamiania kwerendy używającej zarówno slopu, jak i zakreślacza wektorów faktów. Co ciekawe, problem z wydajnością mija podczas wykonywania tego samego zapytania z prostym zakreślaczem i nie jestem pewien, dlaczego tak się dzieje.ElasticSearch and highlighting performance - podświetlacz wektorów prostych i szybkich

Oto metadane dla pola poszukiwany:

contents: { 
    store: true 
    search_analyzer: mySearchAnalyzer 
    term_vector: with_positions_offsets 
    type: string 
} 

Następująca kwerenda, która używa wyróżnienia fakt wektorowych, zajmuje ponad 60 sekund:

{ 
    "size": 500, 
    "query": { 
    "query_string": { 
     "query": "\"CATERPILLAR FINANCIAL SERVICES ASIA PTE LTD\"~5", 
     "fields": [ 
     "contents" 
     ], 
     "default_operator": "and", 
    } 
    }, 
    "highlight": { 
    "fields": { 
     "contents": {} 
    } 
    } 
} 

Jeśli jednak zmienić zapytanie aby użyć analizatora prostego, zajmuje to tylko kilka milisekund:

{ 
    "size": 500, 
    "query": { 
    "query_string": { 
     "query": "\"CATERPILLAR FINANCIAL SERVICES ASIA PTE LTD\"~5", 
     "fields": [ 
     "contents" 
     ], 
     "default_operator": "and", 
    } 
    }, 
    "highlight": { 
    "fields": { 
     "contents": {"type" : "plain"} 
    } 
    } 
} 

Ja ha ve przyjrzeli się różnym opcjom dla zakreślaczy (takich jak: fragment_size, fragment_offset, phrase_limit), ale nic nie jest od razu oczywiste, co można ustawić w celu zwiększenia wydajności.

Jakieś pomysły na to, co się tutaj dzieje? Albo jakiego rodzaju ustawienia mogę spróbować poprawić wydajność?

Uwaga: Jednym z powodów, dla których zmieniliśmy z podświetlacza wektorowego na wektor faktyczny, było to, że niektóre zapytania nie pasowały do ​​zwykłego zakreślacza.

Edit: Dodałem czynności zwielokrotniania, które wykazują tę kwestię w następujący link: https://drive.google.com/file/d/0B-IfDOojIDnIQmpkY2RNN2pMREE/edit?usp=sharing

Myślę, że kluczem jest to, że znajduje się pole, które zawiera wiele podobnych wartościach (m.in. w tym sprawa, Caterpillar jest wielokrotnie przywoływana).

+0

Użyłem with_positions_offsets dla około 20M rekordów i nie ma problemu do tej pory. To nawet szybciej niż "zwykły". Czy możesz podać średnią liczbę rekordów i średnią długość "treści"? Również definicja 'mySearchAnalyzer'. Byłoby dobrze, gdybyś napisał pełny skrypt bash, który tworzy index/inputsomerecords/query i umieścił go w gist dla łatwej analizy. –

+0

To dobry pomysł. Dodałem tutaj kroki do odtworzenia: https://drive.google.com/file/d/0B-IfDOojIDnIQmpkY2RNN2pMREE/edit?usp=sharing. Zauważ, że do odtworzenia problemu wystarczy niewielka ilość danych. – Eric

+0

Przepraszam, że jestem zajęty projektem firmy. Teraz masz trochę wolnego czasu na powrót. Odtworzyłem indeks i nie mogę odtworzyć problemu, może b.c dane nie są wystarczające. Czy BTW wypróbowałeś 'zakreślacz zaksięgowania' (0.90.6+)? Wypróbujmy b.c twoja zawartość wygląda bardzo długo –

Odpowiedz

0

Chociaż nie jest to ściśle odpowiedź na podstawie komentarzy Duc.Duonga, w której nie był on w stanie odtworzyć problemu, próbowałem go odtworzyć w wersji, której używamy (0.90.3) i najnowszej wersji (1.3. 2). Okazuje się, że to się nie powiela z najnowszą wersją - że wyszukiwanie powraca od razu.

Tak więc, ten problem nie powiela się z najnowszą wersją. Nie wiem, gdzie został naprawiony, ale problem występuje w 0.90.3.