什么索引可以加速 X-Hive / Documentum xDB 中的 XQuery？
我的测试数据库中有大约 2500 个文档，搜索 xpath /path/to/@attribute 大约需要 2.4 秒。执行 distinct-values(/path/to/@attribute) 需要 3.0 秒。
通过在 /path/to[ 上添加路径值索引，我已经能够将 但我能想到的索引没有被选取用于更一般的查询。/path/to[@attribute='value'] 上的查询速度加快到数百或数十毫秒。 @attribute
有人知道我应该使用什么索引吗？
I have approx 2500 documents in my test database and searching the xpath /path/to/@attribute takes approximately 2.4 seconds. Doing distinct-values(/path/to/@attribute) takes 3.0 seconds.
I've been able to speed up queries on /path/to[@attribute='value'] to hundreds or tens of milliseconds by adding a Path value index on /path/to[@attribute<STRING>] but no index I can think of gets picked up for the more general query.
Anybody know what indexes I should be using?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您建议的索引是正确的索引（/path/to[@attribute]），但不幸的是，xDB 优化器当前无法识别这种特定情况，因为存储在索引中的“目标节点”始终是一个元素而不是属性。如果 /path/to/@attribute 的结果很少，那么您可以通过稍微修改查询来优化它：distinct-values(/path/to[@attribute]/@attribute)。通过此查询，优化器认识到可以使用一个索引来获取“to”元素，但它仍然可以访问目标文档以检索 @attribute 步骤的属性。这正是为什么它只对点击次数很少的情况有利：每次点击都可能访问不同的数据页。
您还可以做的是直接通过 API 访问索引中的键：XhiveIndexIf.getKeys()。这将非常快，但显然这对用户不太友好（应该由优化器来完成）。
显然优化器可以处理这个问题。我会将其添加到错误跟踪器中。
The index you propose is the correct one (/path/to[@attribute]), but unfortunately the xDB optimizer currently doesn't recognize this specific case since the 'target node' stored in the index is always an element and not an attribute. If /path/to/@attribute has few results then you can optimize this by slightly modifying your query to this: distinct-values(/path/to[@attribute]/@attribute). With this query the optimizer recognizes that there is an index it can use to get to the 'to' element, but then it still has the access the target document to retrieve the attribute for the @attribute step. This is precisely why it will only benefit cases where there are few hits: each hit will likely access a different data page.
What you also can do is access the keys in the index directly through the API: XhiveIndexIf.getKeys(). This will be very fast, but clearly this is not very user friendly (and should be done by the optimizer instead).
Clearly the optimizer could handle this. I will add it to the bug tracker.