Ошибка ложных срабатываний при поиске с использованием подстановочных знаков в Марклогике (например,% что-то% эквивалентно) - PullRequest
Новая
       13

Ошибка ложных срабатываний при поиске с использованием подстановочных знаков в Марклогике (например,% что-то% эквивалентно)

0 голосов
/ 27 июня 2018

У меня есть вопрос относительно поведения поиска с подстановочными знаками в MarkLogic.

По сути, я пытаюсь реплицировать SQL как запрос% что-то%.

Вот код, который возвращает ложные срабатывания: 

xquery version "1.0-ml";
cts:search(/, 
  cts:element-query(fn:QName("","Document"),
  cts:element-word-query(fn:QName("","Information"),"*date*", ("wildcarded"),0), ()),
  'unfiltered')

Несколько заметок:

  • Нефильтрованный вариант должен остаться, потому что производительность необходима.

  • Я использую Unicode Collation и включил:

    • трехсимвольный поиск
    • конечный поиск по шаблону
    • быстрый поиск по конечному подстановочному элементу
    • двухсимвольный поиск
    • поиск одного символа
    • быстрый поиск символа элемента

Что я не понимаю, так это то, почему «* что-то» и «что-то *» возвращают правильные значения, а «* что-то *» возвращает ложные срабатывания? Как я могу это исправить?

Пример ввода:

  1. <Document><Information>another updated document</Information></Document>
  2. <Document><Information>INCUMBENCY CERTIFICATE</Information></Document>
  3. <Document><Information>Certificate of Incumbency</Information></Document>
  4. <Document><Information>something 344_dated 243</Information></Document>
  5. <Document><Information>another terminated document</Information></Document>

Выход:

Все документы совпадают, хотя должны быть возвращены только 1 и 4.

Окончательное редактирование. Единственное, что я хотел бы добавить, - это то, что казалось, что в двух базах данных - в одной с большей нагрузкой документов одни и те же настройки не дают одинаковых результатов. В базе данных с большим количеством документов последние настройки, которые я использовал и которые дают правильные результаты:

  • поиск слова
  • слова позиции
  • тройной индекс
  • быстрый поиск слова по элементу
  • позиция слова элемента
  • быстрый поиск по элементам
  • трехсимвольный поиск
  • трехсимвольные слова
  • быстрый поиск символа элемента
  • конечный поиск по шаблону
  • концевые подстановочные знаки в словах
  • быстрый поиск по подстановочному символу в конце элемента
  • слово лексикон: сопоставление кодов

Ответы [ 2 ]

0 голосов
/ 03 июля 2018

При использовании cts: element-value-query, вы пытались использовать "точные" опции, чтобы получить точные результаты? Попробуйте использовать это один раз и дайте мне знать, как оно себя ведет. Однажды я сталкивался с подобной проблемой.

0 голосов
/ 27 июня 2018

Нефильтрованные подстановочные запросы в определенных элементах (т. Е. Не только с документом) могут возвращать ложные срабатывания без позиционных индексов. Я бы попробовал включить один или оба из word positions и element word positions. Может также стоить проверить, видите ли вы дополнительные улучшения производительности от включения fast element phrase searches.

Возможно, просто потому, что "* что-то и что-то *" содержит больше терминов, оно отфильтровывает ложные срабатывания, а не потому, что оно более точно разрешает эту фразу через индексы.

Обновление: После просмотра обновленного контрольного примера выясняется, что точность индекса подстановочного знака недостаточно высока, если не включен trailing wildcard word positions. Это и three character word positions, по-видимому, необходимы для разрешения этого типа запроса с подстановочными знаками для начальных и конечных элементов.

Я бы порекомендовал отключить one character searches и two character searches, если они не являются строго необходимыми, поскольку они будут генерировать большие индексы. fast element character searches и fast element trailing wildcard searches также не требуются для точности в вашем случае, поэтому вы можете проверить, достаточно ли быстрые ваши запросы без них.

...