Медленный unified highlighting

День добрый!

Очень медленно работает unified highlighting если в analizer используется hunspell filter.
Я понимаю, что многое зависит от словаря... но в моей проблеме задерживается подсветка, а не поиск. Причем очень сильно. Судя по докам надо добавить "index_options:offsets" - но эффекта нет.

Делаю простой опыт - один индекс и один документ с "Войной и миром".
Аналайзер примерно такой:

            "body_analyzer_with_hunspell" : {
              "filter" : [
                "word_delimiter_russian",
                "lowercase",
                "stop_words",
                "protected_words",
                "english_hunspell",
                "russian_hunspell",
                "synonym"
              ],
              "type" : "custom",
              "tokenizer" : "standard"
            },

Просто поиск работает 5 мсек.
Добавляю подсветку к индексу с offsets - 57 СЕКУНД!
Убираю из аналайзера хунспел - 400-800 мсек.
Делаю с term_vector - 300-600мсек.

fvh c term_vector - 100-200 мсек.

Сколько записей вы получаете? Можно в эти 57 секунд запустить hot_threads несколько раз и прислать сюда результат?

Получаю одну запись. Последовательно четыре слова из текста, чтобы нашлось.
Место практически не влияет (начало или конец документа).
Логи через 5 секунд:
https://drive.google.com/drive/folders/1tLbnDPlTMRAvHj-izXPiKyyVJJ5NOIEB?usp=sharing

И какого размера эта запись?

4 слова "прижизненных публикаций текстов Толстого"

{
  "took": 60322,
  "timed_out": false,
  "_shards": {
    "total": 2,
    "successful": 2,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 6.1971927,
    "hits": [
      {
        "_index": "inddoc-1976-10",
        "_type": "searchtype",
        "_id": "pAtOB24Bv-T1AayOjhIh",
        "_score": 6.1971927,
        "inner_hits": {
          "body2": {
            "hits": {
              "total": 1,
              "max_score": 6.1971927,
              "hits": [
                {
                  "_index": "inddoc-1976-10",
                  "_type": "searchtype",
                  "_id": "pAtOB24Bv-T1AayOjhIh",
                  "_nested": {
                    "field": "body2",
                    "offset": 0
                  },
                  "_score": 6.1971927,
                  "highlight": {
                    "body2.txt": [
                      "Пунктуация <em>прижизненных</em> <em>публикаций</em> <em>текстов</em> <em>Толстого</em>, как в большинстве случаев отражающая традицию не"
                    ]
                  }
                }
              ]
            }
          }
        }
      }
    ]
  }
}

Запрос:

q={
  "from": 0, 
  "_source": False,
  "profile":False,
  "size": 1000, 
  "query": {
      "nested": { 

          "inner_hits":{ 
              "_source":False, 
              "highlight" : { 
                  "order":"score", 
                  "number_of_fragments":1,
                  "type":"unified", 
                  #"type":"fvh", 
                  "fields":{ "body2*":{ } 
                      } 
                  }, 
              }, 

          "path": "body2", 
          "score_mode": "sum", 
          "query": { "match": {"body2.txt": {"boost": 3.0, "minimum_should_match": "75%", "prefix_length": 3, "fuzziness": 1, "query": query}}}
          }
      }
  }

P.S. без nested примерно тоже самое.
Сам документ рядом в гугл-драйв положил. Правда там "плоский" вариант. Но там nested не nested невлияет, главное чтобы маппинг совпал.

Ну так с этого и надо было начинать, что вы "Войну и Мир" целиком проиндексировали. :smiley: У вас там, "Людей доброй воли" Жюль Ромена в базе, случайно нет?

А если поискать только слово корректор, то сколько времени занимает?

Дык вчего 6мб. 3,5млн знаков. Какой нибудь отчет за пару лет может и больше весить. И "корректор" ищется так же:

{
  "took": 52125,
  "timed_out": false,
  "_shards": {
    "total": 2,
    "successful": 2,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 0.920828,
    "hits": [
      {
        "_index": "inddoc-1976-10",
        "_type": "searchtype",
        "_id": "pAtOB24Bv-T1AayOjhIh",
        "_score": 0.920828,
        "inner_hits": {
          "body2": {
            "hits": {
              "total": 1,
              "max_score": 0.920828,
              "hits": [
                {
                  "_index": "inddoc-1976-10",
                  "_type": "searchtype",
                  "_id": "pAtOB24Bv-T1AayOjhIh",
                  "_nested": {
                    "field": "body2",
                    "offset": 0
                  },
                  "_score": 0.920828,
                  "highlight": {
                    "body2.txt": [
                      "публикаций текстов Толстого, как в большинстве случаев отражающая традицию не автора, а типографии или <em>корректора</em>"
                    ]
                  }
                }
              ]
            }
          }
        }
      }
    ]
  }
}

Это с offsets или без?

Да.

    "mappings": {
      "searchtype": {
        "properties": {
          "body2": {
            "type": "nested",
            "dynamic": "strict",
            "properties": {
              "txt": {
                "type": "text",
                "index_options": "offsets",
                "fields": {
                  "original": {
                    "type": "text",
                    "index_options": "offsets",
                    "analyzer": "body_analyzer_original"
                  }
                },
                "analyzer": "body_analyzer_with_hunspell",
                "search_analyzer": "search_analyzer"
              }
            }
          },
....

Запрос в точности, как выше - только по "body2.txt"

Я открыл https://github.com/elastic/elasticsearch/issues/48660

Да. на самом деле без fuzziness отрабатывает за 250мсек.

Насколько понял объяснения Jim Ferenczi это не баг, это фича. :slight_smile:
Что при нечетком поиске хайлайтер должен анализировать документ по новой, т.к. неможет взять смещения из index_options.

Но я не понял, почему это не мешает FVH c temp_vector.
Или я что-то понял совсем не так?

Хороший вопрос. Я обсудил это еще раз с Джимом. В случае, когда fuzziness включена, термин в поиске может быть "развернут" в большое количество похожих терминов. В случае с FVH у нас есть маленький словарь терминов для каждого поля, поэтому все эти термины можно найти очень быстро. В случае с постингами, у нас только один большой словарь на все документы, и нахождение всех терминов в нем может занять много времени. Поэтому в случае с fuzziness мы не используем постинги, но используем векторы, если они имеются.

Всё так. Постинг хайлайтеру нужны термы, вхождения которых он и подсветит в документе. В простом случае термы берутся из запроса, но в случае мультитермов *,~ нужно будет перебрать все возможные термы под * вычитать постинги для них и проверит вхождение документа. Что очень долго.
Терм вектор это прямая (не отбратная) структура данных, те из неё можно вычитать только те термы которые входят в документ и другие похожие по fuzzy не перебирать.

Не... что то не срастается.

Вот читаю про term_vector. Содержит список термов, позиции и смещения "букв" (не знаю как по русски)

Читаю про index_options. Содежит тоже самое плюс количество документов, частоты термов....

в чём ключевая разница?

Размер этого списка.

Но ведь index_options мы ставим на конкретное поле и как в этом случае попадает терм с нечетким соответвием не понятно.


slide 18
image

Я думаю, что @Mikhail_Khludnev хотел этим сказать, что в случае с векторами у вас в списке будут только слова из Войны и Мира. В постингах у вас будут еще слова из Анны Карениной, Братьев Карамазовых, и т.д. :smiley:

1 Like

Ну с объемами то ладно, примерно понятно.
Сейчас найду нормальную ссылку на презентацию почитаю. А то ведь в нас умудрились забанить даже слайдшаре... х.з. кому он помешал... видимо терррористы схемы в паверпоинте друг-другу пересылают, или наркоты лунный календарь посева конопли публикуют.