我正在尝试在我的应用程序中实现预先输入，并且我有搜索建议使用文档中建议的元素范围索引。问题是，它不适合我的用例。
任何使用它的人都知道，除非搜索字符串位于被搜索内容的开头，否则它不会返回结果。除非使用前导和尾随通配符，否则不会返回我需要的内容。
我在思考而不是简单地根据术语进行搜索，然后返回结果片段（在我的服务器端代码中截断）作为我的预先输入中的建议。
由于我没有很好的比较性能的方法，所以我希望能够了解这是否合适，或者是否会太慢。
另外，既然它可能会出现在答案中，是的，我已经阅读了关于＆＃34; chunked Element Range Indexes＆＃34;的帖子，但是对于MarkLogic来说是新手，我无法做出正面或反面的结论。它和避风港已经能够适应我的应用程序。
答案 0 :(得分：1)
您提到使用范围索引来填充您的建议，但您也可以使用单词词典。单词词典会根据标记化的字符数据产生建议，而不是整个元素值（或json属性）。可能值得研究。
或者，由于您提到了通配符，因此您可能会感兴趣cts:value-match。它在范围索引的值（而不是单词）上运行，但是将带有粗卡的表达式作为输入。它的表现远比片段方法好得多，后者需要提取和处理实际内容。
HTH！
答案 1 :(得分：1)
我编写了Chunked Element Range Indexes博客文章，并在最后一刻发现我的性能数据在我的索引中被一个令人惊讶的大文档所扭曲。当我删除那个大文档时，许多其他技术（如通配符匹配）突然变得更快。这让我感到惊讶，因为我所使用的所有其他搜索引擎都无法为提前输入方案提供如此快速的性能和灵活性，特别是如果我尝试引入外卡搜索。我决定不公开发布我的帖子，但其他人不小心为我做了这个，所以我们决定把它留在那里，因为它仍然是一个有效的选项。
由于MarkLogic提供了多个通配符索引，因此您可以在该区域中做很多事情。但是，搜索片段不是正确的方法，因为我认为他们会增加一些开销。调用cts：search或其他cts调用以匹配词典。我猜你想要cts：element-value-match。这会对范围索引进行通配符匹配，因为它们都在内存中，所以更快。如果可以，打开数据库上的所有通配符索引。
应该从MarkLogic HTTP服务器中的自定义XQuery脚本调用它。我并不像往常那样推荐REST扩展，因为您需要尽可能地流式传输以正确地执行大多数提前类型的方案（即足够快）。
我建议您找到方法将范围索引中的值集减少到100,000以下，这样就可以减少匹配，并且您不会放弃任何垃圾建议。此外，请确保根据查询的其余部分过滤匹配集（如果用户已经开始键入其他单词或短语）。确保您的HTTP脚本限制了返回的建议数量，因为用户通常无法从一长串建议中受益。并制作一些算法来对建议进行排名，以便最有用的算法使其成为最佳。最后，要非常非常小心，不要提出更有分散意义而不是有用的建议。如果您要提前向用户提前输入，则会中断他们的搜索和思维训练，因此如果您打算建议获胜的搜索词组，请不要打断他们。 ; t帮助他们得到他们想要的东西。即使在主要网站上，我也经常看到这种情况。除非您愿意衡量该功能的使用情况，并在一段时间内对其进行调整，否则请不要将其删除，否则请将其删除。
希望有所帮助！