我目前正在尝试db4o(Java版本)，我非常喜欢我所看到的。但是我不禁怀疑它在真实的实时(网络)环境中的性能如何。是否有人可以分享有关运行db4o的经验(好坏)？

解决方案

回答

我们在大型客户端/服务器项目中运行DB40 .NET版本。

我们的经验是，我们可能会获得比典型的关系数据库更好的性能。

但是，我们实际上必须调整对象才能获得这种性能。例如，如果我们有一个包含很多对象的列表，则这些列表的DB4O激活很慢。有许多方法可以解决此问题，例如，通过反转关系。

另一个痛苦是激活。当我们从DB4O检索或者删除对象时，缺省情况下它将激活整个对象树。例如，加载Foo将加载Foo.Bar.Baz.Bat等，直到没有剩余可加载的内容为止。从编程的角度来看这很不错，但是性能会减慢对象中更多的嵌套。为了提高性能，我们可以告诉DB4O激活多少个级别。如果我们有很多对象，这将很耗时。

另一个痛苦的领域是文本搜索。 DB4O的文本搜索远比SQL全文索引慢得多。 (他们会在他们的网站上直接告诉我们。)好消息是，在DB4O之上设置文本搜索引擎很容易。在我们的项目中，我们已经连接了Lucene.NET来索引所需的文本字段。

某些API似乎不起作用，例如GetField API在应用数据库升级中很有用。 (例如，我们已重命名属性，并且想要升级数据库中的现有对象，则需要使用这些"反射" API在数据库中查找对象。其他API，例如[Index]属性则不不能在稳定的6.4版本中使用，而必须使用不是强类型的Configure()。Index(" someField")指定索引。

我们已经看到，性能会随着数据库的扩大而下降。我们现在有一个1GB的数据库，并且运行速度仍然很快，但不及开始使用小型数据库时的速度。

我们发现了另一个问题，如果该ID在数据库中不再存在，则Db4O.GetByID将关闭数据库。

我们发现本机查询语法(用于查询的最自然的，语言集成的语法)远比不友好的SODA查询慢得多。因此，不要键入：

// C# syntax for "Find all MyFoos with Bar == 23".
// (Note the Java syntax is more verbose using the Predicate class.)
IList<MyFoo> results = db4o.Query<MyFoo>(input => input.Bar == 23);

除了使用漂亮的查询代码外，我们还必须执行一个丑陋的SODA查询，该查询基于字符串并且不是强类型的。

对于.NET人士，他们最近引入了LINQ-to-DB4O提供程序，该提供程序提供了迄今为止最好的语法。但是，性能是否能与丑陋的SODA查询媲美尚待观察。

对DB4O的支持一直不错：我们已经通过电话与他们进行了多次交谈，并获得了有用的信息。他们的用户论坛几乎一文不值，但是，几乎所有问题都没有得到解答。他们的JIRA错误跟踪器引起了很多关注，因此，如果我们遇到了一个令人烦恼的错误，请将其归档到JIRA上通常会得到解决。 (我们已经修复了2个错误，另外一个以半确定的方式进行了修补。)

如果这一切都没有吓到我们，那么让我说，尽管遇到了问题，但我们对DB4O感到非常满意。我们获得的性能使我们尝试过的一些O / RM框架大为失败。我推荐它。

更新时间：2015年7月请记住，这个答案写于2008年。尽管我很感谢大家的支持，但此后世界已经发生了变化，并且此信息可能不如撰写时可靠。

回答

我遇到的主要问题是报告。似乎没有任何方法可以针对db4o数据源运行有效的报告。

回答

大多数本机查询可以在后台高效地转换为SODA查询，因此不会有所作为。当然，首选NQ，因为我们仍处于强类型语言的领域。如果我们在让NQ使用索引方面遇到问题，请随时将问题发布到db4o论坛，我们将尽力。

戈兰

回答

犹大，听起来我们没有使用透明激活，这是最新生产版本(7.4)的功能吗？也许如果我们指定了所使用的版本，那么可能还有其他问题已在最新版本中得到解决？