У меня возникают проблемы с производительностью при использовании подстановочных знаков для поиска определенных комбинаций букв, и я не уверен, что еще мне нужно, чтобы, возможно, улучшить его. Все мои документы следуют шаблону конверта, который выглядит примерно так:Плохая производительность поиска для определенных подстановочных запросов
<pdbe:person-envelope>
<person xmlns="http://schemas.abbvienet.com/people-db/model">
<account>
<domain/>
<username/>
</account>
<upi/>
<title/>
<firstName>
<preferred/>
<given/>
</firstName>
<middleName/>
<lastName>
<preferred/>
<given/>
</lastName>
</person>
<pdbe:raw/>
</pdbe:person-envelope>
У меня есть поле определенное называется имя, которое включает в себя ПгвЬЫате и LastName пути:
{
"field-name": "name",
"field-path": [
{
"path": "/pdbe:person-envelope/pdbm:person/pdbm:firstName",
"weight": 1
},
{
"path": "/pdbe:person-envelope/pdbm:person/pdbm:lastName",
"weight": 1
}
],
"trailing-wildcard-searches": true,
"trailing-wildcard-word-positions": true,
"three-character-searches": true
}
Когда я делаю несколько запросов с помощью поиска: поиск, некоторые вернуться быстро, в то время как другие возвращаются медленно , Это связано с отфильтрованными запросами.
search:search("name:ha*",
<options xmlns="http://marklogic.com/appservices/search">
<constraint name="name">
<word>
<field name="name"/>
</word>
</constraint>
<return-plan>true</return-plan>
</options>
)
Я вижу из плана запроса, что он будет фильтровать все фрагменты 136547 в db. Но этот запрос работает быстро.
<search:query-resolution-time>PT0.013205S</search:query-resolution-time>
<search:snippet-resolution-time>PT0.008933S</search:snippet-resolution-time>
<search:total-time>PT0.036542S</search:total-time>
Однако поиск name:tj*
занимает много времени, а также фильтры по всем из 136547 фрагментов.
<search:query-resolution-time>PT6.168373S</search:query-resolution-time>
<search:snippet-resolution-time>PT0.004935S</search:snippet-resolution-time>
<search:total-time>PT12.327275S</search:total-time>
У меня одинаковые индексы на обоих. Существуют ли какие-либо другие индексы, которые я должен включить, когда я просто выполняю поиск через ограничение поля? У меня есть эти другие индексы, включенные в самой базе данных, в общем.
"collection-lexicon": true,
"triple-index": true,
"word-searches": true,
"word-positions": true
Я пытался делать нефильтрованный запрос, но это не помогло, как я получил кучу матчей на весь документ, а не поля я хотел. Я даже пытался установить корневой фрагмент только на свой элемент person, но это, похоже, не помогло.
"fragment-root": [
{
"namespace-uri": "http://schemas.abbvienet.com/people-db/model",
"localname": "person"
}
]
Спасибо за любые идеи.
В дополнение к тому, что сказал Герт, есть также случаи, когда вместо добавления двухсимвольных шаблонов символов 2 и 3 вы также можете рассмотреть возможность оставить настройки - есть и ввести лексикон слов в рассматриваемом элементе/поле, Затем вы существенно расширяете свой термин на основе элемента-слова. Опять же, это зависит от вашего конечного варианта использования.Вы можете подключить этот подход в качестве настраиваемого ограничения. Его можно даже настроить с помощью таких параметров, как опция «горячий» на cts: match-word-match, а также непосредственно через каждый лес. Что более эффективно/быстрее? Вы должны протестировать и настроить. –
Спасибо за комментарии. Я использую это как пользовательское ограничение. В вариантах поиска (для автозаполнения) я переопределяю термин «обработка» для поиска в этих конкретных полях. Это автозаполнение, чтобы быстро найти нужного человека, как пользователь печатает. Это может быть имя/фамилия, имя пользователя или внутренний идентификатор. По какой-то причине мне показалось, что я где-то читал, что включение трехсимвольных поисков также будет обрабатывать два и один случай символов, но я мог бы неправильно понять это. Включение этих индексов решило проблему. –
Я вижу, где я его неправильно читаю. В документации говорится: «Этот индекс не нужен, если у вас есть три поиска символов и словарный словарь». Как упоминал @DavidEnnis, я мог бы добавить слово lexicon, которого я не сделал. –