我正在尝试了解element word positions
索引设置的影响。
请参阅以下xquery,它返回简单的element-word-query
搜索计划:
xdmp:plan(cts:search(doc(),
cts:and-query(
cts:element-word-query(xs:QName("name"), "element word position")
),
("unfiltered")
))
还有final-plan
(如果未激活索引)(为了节省空间而简化了形式):
<qry:and-query>
<qry:term-query>element(name),pair(word("element"),word("word"))</qry:term-query>
<qry:term-query>element(name),pair(word("word"),word("position"))</qry:term-query>
<qry:term-query>word("element")</qry:term-query>
<qry:term-query>word("word")</qry:term-query>
<qry:term-query>word("position")</qry:term-query>
</qry:and-query>
激活索引(word-positions
以及element word positions
)之后的查询计划:
<qry:and-query>
<qry:term-query>element(name),pair(word("element"),word("word"))</qry:term-query>
<qry:term-query>element(name),pair(word("word"),word("position"))</qry:term-query>
<qry:element-query>
element(name)
<qry:word-query>
<qry:KP pos="0">word("element")</qry:KP>
<qry:KP pos="1">word("word")</qry:KP>
<qry:KP pos="2">word("position")</qry:KP>
</qry:word-query>
</qry:element-query>
</qry:and-query>
所以我认为,由于生成的term-query
少得多,因此,候选片段ID的计数将变小,因此索引分辨率的交集会更快。除此之外,我真的很想了解element-query
的工作原理。所以我有几个问题:
element word positions
,索引中还会保存哪些其他信息?element-query
又如何执行?我看到一个简单的term-query
返回术语键的发布列表的方式,但是我不确定如何评估带有element-query
作为“子查询”的word-query
。 li>
编辑: 添加了一张图片,使我对启用了元素词位置的索引的外观形象化。 (有关详细信息,请参见mholstege的答案注释)
答案 0 :(得分:5)
当您打开职位时,我们会在相关术语的索引中存储每个文档的职位向量,而不仅仅是文档ID。
从叶子查询的特殊性以及计算叶子查询和与中间结果相交方面所做的工作来看,这种思考的方式。
当您在查询计划中看到一个词条查询时,这意味着它只是在查找文档ID,因此不知道相对位置-对于像这样的长短语,结果不太准确,因为“ “单词”和“单词位置”可能出现在文档中的两个单独的父元素中。如果您的数据在每个文档中仅包含一个具有该名称的元素,则不会发生这种情况,尽管您仍可能会出现错误匹配,即两个单词的子短语以相反的顺序出现或由其他单词分隔。>
当您在查询计划中看到单词查询时,这意味着我们将要查看位置,在这里您将看到短语中每个单词的相对位置。解决此问题后,我们将检查位置矢量,并将那些不意味着此位置约束的位置扔掉。因此,所有匹配项将按以下顺序排列以下单词序列:更精确的匹配项。
计划中的element-query还对元素实例相对于元素内部的匹配项施加位置约束。在某些优化中,实际上将元素位置约束下推到查询树的叶子上,以避免过多的中间计算。
您还会看到一些技术上冗余的术语查询:它们的目的是进行简单的术语查询,这些查询可能比叶子词查询更受限制。由于来自与查询的术语列表的交集总是从最短的匹配发布列表开始,因此这可以提供一种快速失败机制,从而避免了更昂贵的职位计算。在这种情况下,存在一定程度的启发式判断,并且鉴于一组复杂的索引选项和查询变体,有时,这些附加术语实际上无济于事。