元素词位置 - 概念性问题
element word positions - conceptual questions
我正在尝试了解 element word positions
索引设置的影响。
请参阅以下 xquery 其中 returns 一个简单 element-word-query
搜索的计划:
xdmp:plan(cts:search(doc(),
cts:and-query(
cts:element-word-query(xs:QName("name"), "element word position")
),
("unfiltered")
))
和final-plan
如果索引未激活(缩减形式保存space):
<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
returns 术语键的发布列表,但我不确定 element-query
和 word-query
作为 "sub-query" 是如何已评估。
编辑:
添加了一张图片以可视化我对启用元素词位置时索引的外观的理解。 (有关详细信息,请参阅 mholstege 的答案评论)
当您打开位置时,我们会在相关术语的索引中存储每个文档的位置向量,而不仅仅是文档 ID。
考虑叶查询的特殊性以及计算它们和交叉中间结果所涉及的工作。
当您在查询计划中看到术语查询时,这意味着它只是在查找文档 ID,因此不知道相对定位——对于像这样的长短语来说,结果不太准确,因为"element word" 和 "word position" 可能出现在文档中两个单独的父元素中。如果您的数据在每个文档中只有一个具有此名称的元素,那是不可能发生的,尽管您仍然可能有错误匹配,其中两个词的子短语以相反的顺序出现,或者被其他词分隔。
当您在查询计划中看到单词查询时,这意味着我们将查看位置,在这里您会看到短语中每个单词的相对位置。当这个问题解决后,我们检查位置向量并剔除那些不意味着这个位置约束的向量。因此所有匹配项都将按以下顺序包含此单词序列:更精确的匹配项。
计划中的元素查询还应用了元素实例相对于元素内匹配项的位置约束。存在优化,其中元素位置约束实际上被下推到查询树的叶子以避免过多的中间计算。
您还会看到一些技术上冗余的术语查询:这些查询的目的是进行简单的术语查找,这些查询可能比叶词查询更受限制。由于 and-query 的术语列表的交集总是从最短匹配的发布列表开始,这可以提供一种快速失败机制来避免更昂贵的位置计算。其中有一定数量的启发式判断,并且给定一组复杂的索引选项和查询变体,有时这些附加术语实际上没有帮助。
我正在尝试了解 element word positions
索引设置的影响。
请参阅以下 xquery 其中 returns 一个简单 element-word-query
搜索的计划:
xdmp:plan(cts:search(doc(),
cts:and-query(
cts:element-word-query(xs:QName("name"), "element word position")
),
("unfiltered")
))
和final-plan
如果索引未激活(缩减形式保存space):
<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
returns 术语键的发布列表,但我不确定element-query
和word-query
作为 "sub-query" 是如何已评估。
编辑:
添加了一张图片以可视化我对启用元素词位置时索引的外观的理解。 (有关详细信息,请参阅 mholstege 的答案评论)
当您打开位置时,我们会在相关术语的索引中存储每个文档的位置向量,而不仅仅是文档 ID。
考虑叶查询的特殊性以及计算它们和交叉中间结果所涉及的工作。
当您在查询计划中看到术语查询时,这意味着它只是在查找文档 ID,因此不知道相对定位——对于像这样的长短语来说,结果不太准确,因为"element word" 和 "word position" 可能出现在文档中两个单独的父元素中。如果您的数据在每个文档中只有一个具有此名称的元素,那是不可能发生的,尽管您仍然可能有错误匹配,其中两个词的子短语以相反的顺序出现,或者被其他词分隔。
当您在查询计划中看到单词查询时,这意味着我们将查看位置,在这里您会看到短语中每个单词的相对位置。当这个问题解决后,我们检查位置向量并剔除那些不意味着这个位置约束的向量。因此所有匹配项都将按以下顺序包含此单词序列:更精确的匹配项。
计划中的元素查询还应用了元素实例相对于元素内匹配项的位置约束。存在优化,其中元素位置约束实际上被下推到查询树的叶子以避免过多的中间计算。
您还会看到一些技术上冗余的术语查询:这些查询的目的是进行简单的术语查找,这些查询可能比叶词查询更受限制。由于 and-query 的术语列表的交集总是从最短匹配的发布列表开始,这可以提供一种快速失败机制来避免更昂贵的位置计算。其中有一定数量的启发式判断,并且给定一组复杂的索引选项和查询变体,有时这些附加术语实际上没有帮助。