简单图形激活的低延迟

Question

我正在使用 db4o 作为一个看起来像语义 wiki 的项目的后端。 我主要关心的是为什么性能这么低？

这里是上下文：

应用程序使用 openJdk6 和 db4o-v8.1。该模型大约有四个继承级别的二十个类，有可激活的集合、引用、uuid、索引等......

通过使用系统时间日志，我发现时间花在了对象操作部分。对于 30 次激活或更新，应用程序平均花费 1.1 秒（提交时不到 1Kb 的数据）。我已经检查了内存（转储），图中只有一小部分是负载（我的数据库大约是 20K 对象和 20Mb），正如透明激活所预期的那样。我几乎从不使用查询，总是使用关系激活。

我在同一台主机上使用客户端-服务器。 db-server 是我们可以在 db4o 网站上找到的示例。客户端-服务器会降低一些性能，但需要并发性。主机依赖于支持大约 300iops 的 fc 存储。

• 可以做些什么来提高性能，减少延迟？
• 我错过了什么吗？
• 有什么技巧我应该知道的吗？

Answer 1

如果您遵循手册，那么问题来自您的数据模型 或使用它。 如果您已经对使用情况进行了所有可能的优化，最后一种方法 是数据模型的更多重构；如果你没有……现在就去做。

所以简短的回答是：不要使用继承，保持关系链尽可能短。

更长的答案：

• 动态性成本很高。 类继承为激活时的方法解析和对象解析添加了动态性。

在 db 之类的休眠/sql 中；继承可以看作是表上的连接，加载一个对象意味着在一个 mush 表中加载多行作为继承级别。所以速度受到连接要求（和连接条件）的限制。

在 db4o 中，当您导航抛出一个对象时，使用对象的所有字段的决定是在用户级别部分完成的；所以所有的对象指针都是加载是激活一个字段的情况。所以对象模型的所有部分都必须从数据库中加载（对于激活的对象）。这与 hibernate/sql db 中发生的情况非常相似。

• 为了避免扫描到糊状模型的部分，并加载糊状激活指针，我们可以重写模型一点。 只需删除所有继承关系并将其替换为指向相应对象的字段即可。

如果 A 扩展 B，则在 B 中添加一个字段，该点位于 A 上并删除扩展关系。然后根据需要使用透明激活从 A 导航到 B。这个技巧在许多领域，数据库中都很有效。它之所以有效，是因为在复杂的图关系中，我们很少在一次计算中使用对象的所有字段。

• 另一个提高性能的解决方案是使用更短的激活路径，要实现这一点，您需要对模型和计算进行大量更改；一种方法是使用快速原生查询，而不仅仅是透明激活。

对于对象数据库性能的晚安阅读，您还可以查看 objectDB。有和db4o一样的问题。