Question

我对MarkLogic中通配符搜索的行为有疑问。

基本上，我想做的是复制SQL，例如％something％查询。

以下是返回误报的代码：

xquery version "1.0-ml";
cts:search(/, 
  cts:element-query(fn:QName("","Document"),
  cts:element-word-query(fn:QName("","Information"),"*date*", ("wildcarded"),0), ()),
  'unfiltered')

一些注意事项：

未过滤的选项必须保留，因为性能是必需的。
我正在使用Unicode排序规则并启用了：
- 三个字符的搜索
- 跟踪通配符搜索
- 快速元素尾随通配符搜索
- 两个字符的搜索
- 一个字符搜索
- 快速元素字符搜索

我不明白的是为什么“ * something”和“ something *”返回正确的值，而“ * something *”却返回假阳性？我该如何解决？

输入示例：

<Document><Information>another updated document</Information></Document>
<Document><Information>INCUMBENCY CERTIFICATE</Information></Document>
<Document><Information>Certificate of Incumbency</Information></Document>
<Document><Information>something 344_dated 243</Information></Document>
<Document><Information>another terminated document</Information></Document>

输出：

所有文档都是匹配的，尽管只返回1和4。

最终编辑：我唯一要补充的是，似乎在两个数据库上-一个数据库带有大量文件，相同的设置不会产生相同的结果。在包含大量文档的数据库上，我使用的最终设置给出了正确的结果是：

单词搜索
单词位置
三重索引
快速元素词搜索
元素词位置
快速元素短语搜索
三个字符的搜索
三个字符的单词位置
快速元素字符搜索
跟踪通配符搜索
跟踪通配符词位置
快速元素尾随通配符搜索
单词词典：代码点整理

Answer 1

特定元素（即，不仅包含文档）中未过滤的通配符查询可能会返回不带位置索引的误报。我会尝试启用word positions和element word positions中的一个或两个。也许值得测试一下，是否通过启用fast element phrase searches看到了其他性能改进。

可能仅仅是因为“ * something and something *”包含更多的术语，它过滤掉了误报，而不是因为它通过索引更准确地解析了该短语。

更新：查看了更新的测试用例后，如果未启用trailing wildcard word positions，则尾随通配符索引的准确性似乎不够好。该和three character word positions似乎是解决这种类型的行踪元素通配符查询所必需的。

如果非严格必要，我建议禁用one character searches和two character searches，因为它们会生成较大的索引。看来fast element character searches和fast element trailing wildcard searches也不是准确性所必需的，因此您可能希望测试没有它们的查询是否足够快。

Answer 2

在使用cts：element-value-query时，您是否尝试使用“精确”选项来获得准确的结果？尝试使用一次，让我知道它的行为。我曾经遇到过类似的问题。

Marklogic通配符搜索误报问题（类似％something％等价的SQL）

2 个答案: