我正在尝试在我的应用程序中实现预先输入，并且我得到了搜索建议，以按照文档中的建议使用元素范围索引。问题是，它不适合我的用例。
任何使用过它的人都知道，除非搜索字符串位于正在搜索的内容的开头，否则它不会返回结果。除非使用前导和尾随通配符，否则这不会返回我需要的内容。
我在想，而不是简单地根据术语进行搜索，然后返回结果片段(在我的服务器端代码中截断)作为我预先输入的建议。
由于我没有比较性能的好方法，因此我希望了解这是否实用，或者是否会太慢。
另外，由于它可能会出现在答案中，是的，我已经阅读过有关“分块元素范围索引”的文章，但作为 MarkLogic 的新手，我无法弄清楚它的情况，也无法使其适应我的应用程序。
最佳答案
我写了分块元素范围索引博客文章，并在最后一刻发现我的性能数据因索引中令人惊讶的大文档而出现偏差。当我删除那个大文档时，许多其他技术(例如通配符匹配)突然变得更快。这让我感到惊讶，因为我使用的所有其他搜索引擎都无法为提前输入场景提供如此快速的性能和灵 active ，特别是如果我尝试引入通配符搜索。我决定不公开推送我的帖子，但其他人不小心为我做了这件事，所以我们决定将其保留在那里，因为它仍然提供了一个有效的选项。
由于 MarkLogic 提供了多个通配符索引，因此您在该领域确实可以做很多事情。然而，搜索片段并不是执行此操作的正确方法，因为我相信它们会增加一些开销。调用 cts:search 或其他 cts 调用之一来匹配词典。我猜你会想要 cts:element-value-match。这会针对范围索引进行通配符匹配，因为它们都在内存中，所以速度更快。如果可以的话，打开数据库上的所有通配符索引。
它应该从 MarkLogic HTTP 服务器中的自定义 XQuery 脚本调用。我并不像通常那样推荐 REST 扩展，因为您需要尽可能精简才能正确执行大多数预输入场景(即足够快)。
我建议您找到方法将范围索引中的值集减少到 100,000 以下，这样可以匹配的内容就会减少，并且您不会接受任何垃圾建议。另外，请确保根据查询的其余部分过滤匹配项(如果用户已经开始输入其他单词或短语)。确保您的 HTTP 脚本限制返回的建议数量，因为用户通常无法从一长串建议中受益。并设计一些算法对建议进行排名，以便最有帮助的建议排在最前面。最后，要非常非常小心，不要提出那些分散注意力而不是有帮助的建议。如果您要让用户提前输入，这会打断他们的搜索和思路，因此，如果您要建议的搜索短语无法帮助他们获得他们想要的内容，请不要打断他们。我经常看到这种方式，甚至在主要网站上也是如此。除非您愿意衡量该功能的使用情况，并随着时间的推移对其进行调整，或者在它分散用户注意力时将其删除，否则不要进行提前输入。
希望有帮助!
关于java - 使用片段作为搜索建议是否实用？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42302211/