2016-06-06 2 views
0

У меня возникают проблемы с производительностью при использовании подстановочных знаков для поиска определенных комбинаций букв, и я не уверен, что еще мне нужно, чтобы, возможно, улучшить его. Все мои документы следуют шаблону конверта, который выглядит примерно так:Плохая производительность поиска для определенных подстановочных запросов

<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" 
    } 
    ] 

Спасибо за любые идеи.

ответ

3

Корни фрагмента полезны, если вы хотите использовать выражение для поиска для этого элемента человека и, главным образом, если оно встречается несколько раз в одном документе. Это не приведет к тому, что ваш текущий поиск ограничит этот элемент.

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

Поисковые фразы, упомянутые выше, содержат два символа с подстановочным знаком. Поскольку вы включили только три символа, ему пришлось полагаться на фильтрацию. Тот факт, что некоторые работают быстро, некоторые медленные, вероятно, из-за кеширования. Если вы повторите тот же запрос, MarkLogic вернет результат из кеша.

Для тестирования производительности вам придется либо регулярно перезапускать MarkLogic, чтобы сбрасывать кеши, либо искать в (полу) случайные строки, чтобы избежать возможности использования MarkLogic. Или, возможно, оба ..

HTH!

+0

В дополнение к тому, что сказал Герт, есть также случаи, когда вместо добавления двухсимвольных шаблонов символов 2 и 3 вы также можете рассмотреть возможность оставить настройки - есть и ввести лексикон слов в рассматриваемом элементе/поле, Затем вы существенно расширяете свой термин на основе элемента-слова. Опять же, это зависит от вашего конечного варианта использования.Вы можете подключить этот подход в качестве настраиваемого ограничения. Его можно даже настроить с помощью таких параметров, как опция «горячий» на cts: match-word-match, а также непосредственно через каждый лес. Что более эффективно/быстрее? Вы должны протестировать и настроить. –

+0

Спасибо за комментарии. Я использую это как пользовательское ограничение. В вариантах поиска (для автозаполнения) я переопределяю термин «обработка» для поиска в этих конкретных полях. Это автозаполнение, чтобы быстро найти нужного человека, как пользователь печатает. Это может быть имя/фамилия, имя пользователя или внутренний идентификатор. По какой-то причине мне показалось, что я где-то читал, что включение трехсимвольных поисков также будет обрабатывать два и один случай символов, но я мог бы неправильно понять это. Включение этих индексов решило проблему. –

+0

Я вижу, где я его неправильно читаю. В документации говорится: «Этот индекс не нужен, если у вас есть три поиска символов и словарный словарь». Как упоминал @DavidEnnis, я мог бы добавить слово lexicon, которого я не сделал. –

Смежные вопросы