0

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

这是上下文：

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

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

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

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

1 回答 1

0

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

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

更长的答案：

  • 活力成本很高。类继承在激活时为方法解析和对象解析增加了活力。

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

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

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

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

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

对于对象数据库性能的晚安阅读，您还可以查看 objectDB。存在与 db4o 中相同的问题。

于 2013-07-08T23:05:22.807 回答