db4o experiences?我目前正在尝试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查询慢得多。因此，不要键入：
除了使用漂亮的查询代码外，您还必须执行一个丑陋的SODA查询，该查询基于字符串并且不是强类型的。 对于.NET人士，他们最近引入了LINQ-to-DB4O提供程序，该提供程序提供了迄今为止最好的语法。但是，尚待观察丑陋的SODA查询是否能达到性能。 对DB4O的支持一直不错：我们已经通过电话与他们进行了多次交谈，并获得了有用的信息。他们的用户论坛几乎一文不值，但是，几乎所有问题都没有得到解答。他们的JIRA错误跟踪器引起了很多关注，因此，如果您遇到了一个令人烦恼的错误，请将其归档到JIRA上通常会得到解决。 (我们已经修复了2个错误，另外一个以半确定的方式进行了修补。) 如果这一切还没有吓到您，那么让我说，尽管遇到了问题，但我们对DB4O感到非常满意。我们获得的性能使我们尝试过的一些O / RM框架大为失败。我推荐它。 更新时间：2015年7月请记住，这个答案写于2008年。尽管我很感谢大家的支持，但此后世界已经发生了变化，并且此信息可能不如撰写时可靠。 大多数本机查询可以并且可以高效地转换为幕后SODA查询，因此不会有所作为。使用NQ当然是首选，因为您仍处于强类型语言的领域。如果您在让NQ使用索引时遇到问题，请随时将您的问题发布到db4o论坛，我们将尽力帮助您。 戈兰 我遇到的主要问题是报告。似乎没有任何方法可以针对db4o数据源运行有效的报告。 犹大，听起来您没有使用透明激活，这是最新生产版本(7.4)的功能吗？ 也许如果您指定了所使用的版本，那么可能还有其他问题已在最新版本中得到解决？ |
