schlechte Suchleistung für bestimmte Platzhalterabfragen

Question

Ich habe Leistungsprobleme bei der Verwendung von Wildcard-Suche nach bestimmten Buchstabenkombinationen, und ich bin mir nicht sicher, was ich sonst noch verbessern muss. Alle meine Dokumente folgen einem Umschlagmuster, das ungefähr wie folgt aussieht.

<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> 

Ich habe ein Feld namens Name definiert, die den Vor- und den Nachnamen Pfade umfasst:

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

Wenn ich einige Abfragen tun mit Suche: Suche, einige kommen schnell zurück, während andere wieder langsam . Dies ist mit den gefilterten Abfragen.

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> 
) 

Ich kann aus dem Abfrageplan sehen, dass es über alle 136547 Fragmente in der DB filtern wird. Aber diese Abfrage funktioniert schnell.

<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> 

jedoch eine Suche nach name:tj* dauert eine lange Zeit, und filtert auch alle der 136.547 Fragmente über.

<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> 

Ich habe die gleichen Indizes für beide. Gibt es weitere Indizes, die ich aktivieren sollte, wenn ich gerade eine Suche über die Feldbeschränkung durchführe? Ich habe diese anderen Indizes im Allgemeinen in der Datenbank selbst aktiviert.

"collection-lexicon": true, 
    "triple-index": true, 
    "word-searches": true, 
    "word-positions": true 

Ich habe versucht, eine ungefilterte Abfrage zu tun, aber das half nicht, wie ich ein paar Streichhölzer auf das gesamte Dokument bekam, und nicht auf die Felder wollte ich. Ich habe sogar versucht, das Wurzelfragment nur auf mein persönliches Element zu setzen, aber das schien den Dingen nicht zu helfen.

"fragment-root": [ 
    { 
     "namespace-uri": "http://schemas.abbvienet.com/people-db/model", 
     "localname": "person" 
    } 
    ] 

Danke für irgendwelche Ideen.

Answer 1

Fragmentstämme sind hilfreich, wenn Sie einen suchbaren Ausdruck für dieses Personenelement verwenden möchten, und meistens, wenn es mehrmals in einem Dokument vorkommt. Dadurch wird Ihre aktuelle Suche nicht auf dieses Element beschränkt.

In Ihrem Fall haben Sie eine Reihe von relevanten Optionen aktiviert, aber die Platzhalteroption funktioniert nur für 4 Zeichen oder mehr. Wenn Sie nach Platzhaltern mit weniger Zeichen suchen möchten, müssen Sie die Suchoptionen für drei, zwei und ein Zeichen aktivieren.

Die oben genannten Suchbegriffe enthielten jeweils zwei Zeichen mit einem Platzhalter. Da Sie nur die Option mit drei Zeichen aktiviert haben, musste sie sich auf die Filterung verlassen. Die Tatsache, dass einige schnell laufen, manche langsam, liegt wahrscheinlich am Caching. Wenn Sie dieselbe Abfrage wiederholen, gibt MarkLogic das Ergebnis aus dem Cache zurück.

Für Leistungstests müssen Sie MarkLogic entweder regelmäßig neu starten, um Caches zu leeren, oder nach (halb-) zufälligen Strings suchen, um zu verhindern, dass MarkLogic zwischenspeichern kann. Oder vielleicht beides ..

HTH!