實際使用片段作爲搜索建議？

Question

我想在我的應用程序中實現type-ahead，並且我得到了搜索建議使用文檔中建議的元素範圍索引。問題是，它不適合我的用例。

由於任何使用過它的人都知道，除非搜索字符串位於搜索內容的開頭，否則不會返回結果。除了使用前導和尾隨通配符外，這不會返回我所需要的。

我想的不是簡單地根據術語進行搜索，然後返回結果片段（在我的服務器端代碼中截斷）作爲我的輸入提示中的建議。

由於我沒有比較表現的好方法，所以我希望對此有所洞察，以確定這是否實用，否則會太慢。

此外，它可能出現的答案，因爲，是的，我看了一下「分塊要素範圍索引」的帖子，但作爲新MarkLogic，我不能讓元首或它的尾巴，一直沒能夠適應它到我的應用程序。

Answer 1

我寫了分塊元素範圍索引博客文章，最後發現我的表現數字被我的索引中一個令人驚訝的大文檔歪曲。當我刪除這個大文檔時，其他許多技術（如通配符匹配）突然快得多。這令我感到驚訝，因爲我用過的所有其他搜索引擎都無法爲類型預測場景提供如此快速的性能和靈活性，特別是當我嘗試引入通配符搜索時。我決定不公開發表我的帖子，但其他人不小心爲我做了這件事，所以我們決定放棄它，因爲它仍然提供了一個有效的選擇。

由於MarkLogic提供了多個通配符索引，因此您可以在該區域進行很多操作。但是，搜索片段不會是正確的方式，因爲我相信它們會增加一些開銷。呼叫cts：搜索或其他cts呼叫之一以匹配詞典。我猜你想要cts：element-value-match。這是通配符匹配的範圍索引，因爲它們都在內存中，所以更快。如果可以，打開你的數據庫的所有通配符索引。

它應該從MarkLogic HTTP服務器中的自定義XQuery腳本調用。我不會像往常一樣推薦REST擴展，因爲您需要儘可能使用流式傳輸來正確執行大多數預先輸入的場景（即足夠快）。

我建議你找到方法來縮小範圍索引中的值集合，使其小於100,000，這樣可以減少匹配次數，並且不會讓任何垃圾建議。此外，請確保您根據查詢的其餘部分過濾了一組匹配項（如果用戶已經開始輸入其他詞或短語）。確保您的HTTP腳本限制了返回的建議數量，因爲用戶通常無法從一長串建議中獲益。並制定一些算法來排列建議，以便最有幫助的建議達到頂端。最後，要非常小心，不要提出比分散注意力更有用的建議。如果你打算讓用戶提前輸入，它會中斷他們的搜索和思維訓練，所以如果你要建議搜索短語來幫助他們得到他們想要的東西，那麼不要打斷他們。 。即使在主要網站上，我也經常看到這種情況。除非您願意衡量該功能的使用情況，否則不要進行提前輸入，並隨時調整它，或者在分散注意力的用戶時將其刪除。

希望有幫助！

Answer 2

你提到你正在使用範圍索引來填充你的建議，但你也可以使用單詞詞典。單詞詞典會根據標記字符數據產生建議，而不是整個元素（或json屬性）的值。這可能值得研究。

或者，由於您提到了通配符，因此您可能會對cts:value-match感興趣。它在範圍索引的值（不是單詞）上運行，但採用狂放表達式作爲輸入。它將比片段方法表現得更好，因爲片段方法需要提取並處理實際內容。

HTH！