我正在尝试在我的应用程序中实现预先输入，并且我得到了搜索建议，以使用文档中推荐的元素范围索引。问题是，它不适合我的用例。
任何使用过它的人都知道，除非搜索字符串位于被搜索内容的开头，否则它不会返回结果。除非使用前导通配符和尾随通配符，否则这不会返回我需要的内容。
我在考虑，而不是简单地根据术语进行搜索，然后返回结果 sn-ps（在我的服务器端代码中被截断）作为我预先输入的建议。
由于我没有比较性能的好方法，因此我希望了解这是否实用，或者是否会太慢。
另外，由于它可能出现在答案中，是的，我已经阅读了有关“分块元素范围索引”的帖子，但是作为 MarkLogic 的新手，我无法对它做出正面或反面，也无法使其适应我的应用程序。
【问题讨论】：
标签： java marklogic marklogic-8
我写了 Chunked Element Range Indexes 博客文章，并在最后一分钟发现我的性能数据因索引中的一个惊人的大文档而出现偏差。当我删除那个大文档时，通配符匹配等许多其他技术突然变得更快了。这让我感到惊讶，因为我使用的所有其他搜索引擎都无法为预输入场景提供如此快速的性能和灵活性，特别是如果我尝试引入通配符搜索。我决定不公开发布我的帖子，但其他人不小心为我做了，所以我们决定将其保留在那里，因为它仍然是一个有效的选项。
由于 MarkLogic 提供了多个通配符索引，因此您可以在该领域做很多事情。但是，搜索 sn-ps 不是正确的方法，因为我相信它们会增加一些开销。调用 cts:search 或其他 cts 调用之一来匹配词典。我猜你会想要 cts:element-value-match。这确实与范围索引进行通配符匹配，因为它们都在内存中，所以速度更快。如果可以，请打开数据库上的所有通配符索引。
应该从 MarkLogic HTTP 服务器中的自定义 XQuery 脚本调用它。我不会像往常一样推荐 REST 扩展，因为您需要尽可能精简才能正确执行大多数预先输入的场景（也就是说，足够快）。
我建议您想办法将范围索引中的值集缩减到小于 100,000，这样可以匹配的值更少，并且您不会让任何垃圾建议出现。此外，请确保根据查询的其余部分过滤匹配集（如果用户已经开始输入其他单词或短语）。确保您的 HTTP 脚本限制返回的建议数量，因为用户通常无法从一长串建议中受益。并设计一些算法来对建议进行排名，以便最有帮助的建议排名靠前。最后，要非常非常小心，不要提出更分散注意力而不是有用的建议。如果您要让您的用户提前输入，它会打断他们的搜索和思路，所以如果您要建议的搜索短语不会帮助他们获得他们想要的东西，请不要打断他们.我经常看到这种方式，即使在主要网站上也是如此。除非您愿意衡量该功能的使用情况，并随着时间的推移对其进行调整，否则不要进行预先输入，如果它会分散用户的注意力，则将其删除。
希望对您有所帮助！
【讨论】：
您提到您正在使用范围索引来填充您的建议，但您也可以使用单词词典。单词词典会根据标记化的字符数据生成建议，而不是元素的整个值（或 json 属性）。这可能值得研究。
或者，既然您提到了通配符，那么您可能会对cts:value-match 感兴趣。它在范围索引中的值（而不是单词）上运行，但将通配符表达式作为输入。它的性能要比 sn-p 方法好得多，后者需要拉起并处理实际内容。
HTH！
【讨论】：