Запрос префикса Elasticsearch minhash с подстановочными знаками?

#elasticsearch #wildcard #prefix #minhash

#elasticsearch #подстановочный знак #префикс #minhash

Вопрос:

У меня есть поле minhash, сгенерированное для некоторого текста (на основе алгоритма minhash), теперь мой вопрос в том, можно ли как-то дополнить или добавить запрос префикса с помощью подстановочных знаков? Проблема в том, что хэшированные строковые значения основаны на содержимом (текстовом) положении элементов / токенов. Таким образом, первые несколько символов (префикс) не всегда могут точно соответствовать похожему содержимому. Можно ли добавить подстановочный знак, например *3AF8659GJ перед префиксом для запроса?

РЕДАКТИРОВАТЬ: Я думаю, я недостаточно серьезно думал о проблеме. Различия в хэше могут быть в любом месте хэш-строки (на основе текстовых различий в позиции содержимого разницы текста). Итак, я думаю, что «лучшим» единственным способом было бы изменить расстояние и некоторый порог.

Например, поместите все хэши в массив и отсортируйте их в лексическом порядке (или как бы вы отсортировали шестнадцатеричные строки?) и затем вы сравниваете следующие k документов только до тех пор, пока не будет достигнут порог расстояния редактирования, и помещаете дубликаты в отдельный массив..

Комментарии:

1. Итак, ваша идея заключается в сравнении только суффикса? Если да, готовы ли вы переиндексировать свои данные?

2. смотрите мой комментарий ниже, я думал сначала сравнить префикс, но может случиться так, что различия в тексте могут появиться не только в начале, но и в конце или где угодно, поэтому расстояние редактирования, я думаю, лучший подход. Но нечеткий поиск смешон только с двумя расстояниями редактирования. Мне пришлось бы реализовать пользовательский поиск в Node.js на основе расстояния редактирования..

Ответ №1:

Поиск по суффиксам настоятельно не рекомендуется по соображениям производительности, как объясняется в официальном документе:

Чтобы предотвратить чрезвычайно медленные запросы с подстановочными знаками, термин с подстановочными знаками не должен начинаться с одного из подстановочных знаков * или ?

Все еще есть способ достичь желаемого с помощью умно созданного анализатора. Идея состоит в том, чтобы индексировать только конец minhash. Вы можете добиться этого, как описано ниже.

Сначала создайте индекс с помощью следующего анализатора:

 PUT minhash-index
{
  "settings": {
    "index": {
      "analysis": {
        "analyzer": {
          "suffix": {
            "type": "custom",
            "tokenizer": "keyword",
            "filter": [
              "lowercase",
              "reverse",
              "substring",
              "reverse"
            ]
          }
        },
        "filter": {
          "substring": {
            "type": "edgeNGram",
            "min_gram": 1,
            "max_gram": 10
          }
        }
      }
    }
  },
  "mappings": {
    "doc": {
      "properties": {
        "minhash": {
          "type": "text",
          "analyzer": "suffix",
          "search_analyzer": "standard"
        }
      }
    }
  }
}
  

Идея suffix анализатора заключается в том, что он будет индексировать все суффиксы длиной от 1 до 10 (вы можете индексировать более длинные суффиксы) для каждого minhash, который вы добавили в свой индекс.

Так, например, для minhash C50FD711C2C43287351892A4D82F44B055F048C46D2C54197AC1D1E921F11E6699C4057C4B93907518E6DCA51A672D3D3E419160DAE276CB7716D11B94D8C3BB2E4A591329B7AF973D17A7F9336342FFAAFD4D он будет индексировать все следующие суффиксы:

  • d
  • 4d
  • d4d
  • fd4d
  • afd4d
  • aafd4d
  • faffd4d
  • ffaafd4d
  • 2ffaafd4d
  • 42ffaafd4d

Затем вы можете легко выполнить поиск и найти указанный выше minhash с помощью следующего запроса:

 POST minhash-index/_search
{
  "query": {
    "match": {
      "minhash": "42FFAAFD4D"
    }
  }
}
  

Комментарии:

1. большое спасибо, это хороший подход, однако проблема в том, что невозможно заранее определить, в чем различия / сходства на основе содержимого двух документов. Позиции хэш-ключей minhash для отдельных шестнадцатеричных хэшей просто объединяются вместе, и они вычисляются на основе фрагментов текста. Таким образом, это зависит от различий в позиции текстового содержимого от того, где находятся различия в хэш-ключе. Это может быть в начале, или в конце, или где-то посередине. Другим подходом было бы расстояние редактирования документа по сравнению с другими документами.

2. Итак, я подумал о другом подходе, при котором я сначала извлекаю все документы и помещаю их в массив. Затем я сортирую документы в порядке сортировки minhash и сравниваю только следующие k документов на основе некоторого расстояния редактирования, чтобы обнаружить дубликаты…