调整 Jackrabbit 数据模型(VERSION_BUNDLE 表)

Posted

技术标签:

【中文标题】调整 Jackrabbit 数据模型(VERSION_BUNDLE 表)【英文标题】:Tuning Jackrabbit data model (VERSION_BUNDLE table) 【发布时间】:2012-06-11 11:38:19 【问题描述】:

作为我们应用程序的一部分,我们使用 Jackrabbit (1.6.4) 来存储文档。我们的应用程序检索到的每个文档都放入 Jackrabbit 中的文件夹结构中,如果不存在则创建该文件夹结构。

我们的 DBA 注意到以下查询对持有 Jackrabbit 模式的 Oracle (11.2.0.2.0) 数据库执行了很多次 - 每小时超过 50000 次,导致数据库上的大量 IO。事实上,它是 IO over elapsed time (97% IO) 方面排名前 5 位的 SQL 语句之一:

    select BUNDLE_DATA from VERSION_BUNDLE where NODE_ID = :1

查看数据库,您会注意到该表最初只包含一条记录,包括 node_id(数据类型 RAW)键和 DEADBEEFFACEBABECAFEBABECAFEBABE 值,然后是 bundle_data 中的几个字节BLOB 列。稍后,会添加更多记录以及其他数据。

表的 SQL 如下所示:

CREATE TABLE "VERSION_BUNDLE"
(    
    "NODE_ID" RAW(16) NOT NULL ENABLE,
    "BUNDLE_DATA" BLOB NOT NULL ENABLE
);

我有以下问题:

为什么 Jackrabbit 如此频繁地访问此表? 是否有任何 Jackrabbit 调整选项可以加快速度? Jackrabbit 是否更改了 BUNDLE_DATA 值,还是只是在每次访问存储库时读取它? 是否有任何方法可以调整数据库架构以使其更好地应对这种情况?

更新:该表最初仅包含一条记录,随着时间的推移添加更多记录,由 Jackrabbit 内部决定。在大多数情况下,访问似乎仍然是只读的,因为插入或更新语句未报告为以高数量运行。

【问题讨论】:

嗨@nwinkler,你明白这个问题吗?我们遇到了同样的问题,谢谢 对不起,我问这个问题已经六年多了 - 我不记得我们做了什么来解决这个问题...... 谢谢,你能给我指个能记住的人吗?对我来说,了解更多关于这个问题非常重要,如果可以的话,我可以给你我的邮件地址 r.gambelli@hitachi-systems-cbt.com 【参考方案1】:

这是物理 I/O 还是逻辑 I/O?随着数据被读取,如果块在缓存中的老化速度足够快以至于需要物理 i/o,我会感到惊讶。

【讨论】:

我不是 DBA,但我猜这是逻辑 IO。 AWR 报告显示了“按用户 I/O 等待时间排序的 SQL”下的语句,而不是“按读取的 SQL 排序”下的语句。 清除它的一种方法是查看 v$segment_statistics 视图,该视图将分解表和任何相关索引的逻辑和物理 i/o。然后,您可以与其他细分市场进行比较,看看它是否真的是整个系统的重要 i/o 水平【参考方案2】:

如果 JCR-Store 基于 Oracle 数据库,您可以重新组织基础表。

    为该表构建一个hash-cluster 以防止索引访问 检查您是否拥有使用partitioning option 的许可 删除应用程序行中不必要的版本将被删除(版本修剪)

如果您要存储图片、文档等二进制对象 - 只需查看 VERSION_BINVAL。

【讨论】:

【参考方案3】:

为什么 Jackrabbit 如此频繁地访问此表?

这表明您正在存储库中创建版本。这是您的应用程序应该做的事情吗?

是否有任何 Jackrabbit 调整选项可以加快速度?

我不知道;调查的一种选择是升级到更新的 Jackrabbit 版本。 Version 2.4.2 刚刚发布,1.6.4 已经快两年了。这些版本之间的性能可能有所改进。

BUNDLE_DATA 值是被 Jackrabbit 改变了,还是只是在每次访问存储库时读取?

从外观上看,它是根存储库节点的 GUID。

有没有办法调整数据库架构以使其更好地处理这种情况?

据我所知,模式是由 Jackrabbit 自动生成的,因此唯一的选择是在创建表定义后以兼容的方式修改它。但这是 DBA 的主题,我不是。

【讨论】:

感谢您的回复!更新到 2.x 目前不是一种选择。我已经更新了我的问题,该表包含多个记录 - 最初只有根节点,但随着时间的推移会添加其他记录。这仍然不能解释为什么这个表被如此频繁地访问以及为什么访问需要这么多时间。 @nwinkler 那么这表明您正在存储库中创建版本。这是您的应用程序应该做的事情吗? 是的,我们将版本控制作为应用程序的一部分。所以 VERSION_BUNDLE 中的记录是有意义的。我们目前正在挖掘应用程序代码,以查看应用程序可以在哪里访问 Jackrabbit,其模式类似于我们在 DB 上看到的模式。针对 Jackrabbit 的查询量与我们预期的相差一个数量级(或接近该数量级)。【参考方案4】:

为什么 Jackrabbit 如此频繁地访问此表?

我们已经看到,即使您不要求版本,也经常访问此表。 看看来自 Jackrabbit 用户邮件列表的to this thread

【讨论】:

以上是关于调整 Jackrabbit 数据模型(VERSION_BUNDLE 表)的主要内容,如果未能解决你的问题,请参考以下文章

将元数据存储到 Jackrabbit 存储库中

混合模式下使用 H2 数据库的 Jackrabbit 集群

Jackrabbit仓库的运维管理

JackRabbit Oak:我的应用程序需要很长时间才能启动/重新启动

Apache Jackrabbit 和 Jackrabbit Oak 有啥区别?

CPU 负载问题 (Magnolia-5.3.3 Jackrabbit-2.8.0)