db4o体验? [英] db4o experiences?

查看:115
本文介绍了db4o体验?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在尝试db4o(java版本),我非常喜欢我所看到的。但我不禁想知道它在真实的(网络)环境中的表现如何。有没有人有任何关于运行db4o的经验(好的或坏的)?

I'm currently trying out db4o (the java version) and I pretty much like what I see. But I cannot help wondering how it does perform in a real live (web-)environment. Does anyone have any experiences (good or bad) to share about running db4o?

推荐答案

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

We run DB40 .NET version in a large client/server project.

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

Our experiences is that you can potentially get much better performance than typical relational databases.

然而,你真的必须调整你的对象以获得这种性能。例如,如果您有一个包含大量对象的列表,则这些列表的DB4O激活速度很慢。有很多方法可以解决这个问题,例如,通过颠倒关系。

However, you really have to tweak your objects to get this kind of performance. For example, if you've got a list containing a lot of objects, DB4O activation of these lists is slow. There are a number of ways to get around this problem, for example, by inverting the relationship.

另一个痛苦就是激活。从DB4O检索或删除对象时,默认情况下它将激活整个对象树。例如,加载Foo将加载Foo.Bar.Baz.Bat等,直到没有任何东西可以加载。虽然从编程的角度来看这很好,但性能会降低对象中嵌套的速度。为了提高性能,您可以告诉DB4O要激活多少级别。如果你有很多对象,这很费时间。

Another pain is activation. When you retrieve or delete an object from DB4O, by default it will activate the whole object tree. For example, loading a Foo will load Foo.Bar.Baz.Bat, etc until there's nothing left to load. While this is nice from a programming standpoint, performance will slow down the more nesting in your objects. To improve performance, you can tell DB4O how many levels deep to activate. This is time-consuming to do if you've got a lot of objects.

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

Another area of pain was text searching. DB4O's text searching is far, far slower than SQL full text indexing. (They'll tell you this outright on their site.) The good news is, it's easy to setup a text searching engine on top of DB4O. On our project, we've hooked up Lucene.NET to index the text fields we want.

有些API似乎不起作用,例如GetField API有用在应用数据库升级。 (例如,您重命名了一个属性,并且想要升级数据库中的现有对象,您需要使用这些反射API来查找数据库中的对象。其他API,例如[Index]属性不要在稳定的6.4版本中工作,你必须使用Configure()。索引(someField)来指定索引,它不是强类型的。

Some APIs don't seem to work, such as the GetField APIs useful in applying database upgrades. (For example, you've renamed a property and you want to upgrade your existing objects in the database, you need to use these "reflection" APIs to find objects in the database. Other APIs, such as the [Index] attribute don't work in the stable 6.4 version, and you must instead specify indexes using the Configure().Index("someField"), which is not strongly typed.

我们'我们见证了性能会降低数据库的规模。我们现在拥有1GB的数据库,但事情仍然很快,但并不像我们开始使用小型数据库时那么快。

We've witnessed performance degrade the larger your database. We have a 1GB database right now and things are still fast, but not nearly as fast as when we started with a tiny database.

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

We've found another issue where Db4O.GetByID will close the database if the ID doesn't exist anymore in the database.

我们发现了Native Query语法(最自然,语言集成的查询语法)比不太友好的SODA查询慢得多。所以不要输入:

We've found the Native Query syntax (the most natural, language-integrated syntax for queries) is far, far slower than the less-friendly SODA queries. So instead of typing:

// 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查询,这是一个基于字符串的丑陋查询而不是强类型。

Instead of that nice query code, you have to an ugly SODA query which is string-based and not strongly-typed.

对于.NET人员,他们最近推出了一个LINQ-to-DB4O提供程序,它提供了最好的语法。然而,尚未看到性能是否会与丑陋的SODA查询相提并论。

For .NET folks, they've recently introduced a LINQ-to-DB4O provider, which provides for the best syntax yet. However, it's yet to be seen whether performance will be up-to-par with the ugly SODA queries.

DB4O支持一直不错:我们已经和他们谈过了手机多次,并收到了有用的信息。他们的用户论坛几乎毫无价值,但几乎所有的问题都没有得到答复。他们的JIRA bug跟踪器受到了很多关注,所以如果你有一个唠叨的bug,在JIRA上提交它通常会得到修复。 (我们已经修复了2个错误,另有一个错误修复了。)

DB4O support has been decent: we've talked to them on the phone a number of times and have received helpful info. Their user forums are next to worthless, however, almost all questions go unanswered. Their JIRA bug tracker receives a lot of attention, so if you've got a nagging bug, file it on JIRA on it often will get fixed. (We've had 2 bugs that have been fixed, and another one that got patched in a half-assed way.)

如果这一切都没有让你害怕尽管我们遇到了问题,但我还是说我们对DB4O非常满意。我们所获得的性能已经破坏了我们尝试过的一些O / RM框架。我推荐它。

If all this hasn't scared you off, let me say that we're very happy with DB4O, despite the problems we've encountered. The performance we've got has blown away some O/RM frameworks we tried. I recommend it.

2015年7月更新请记住,这个答案是在2008年写的。虽然我很欣赏这些赞成,但世界已经从那以后发生了变化,这些信息可能不如写入时那么可靠。

update July 2015 Keep in mind, this answer was written back in 2008. While I appreciate the upvotes, the world has changed since then, and this information may not be as reliable as it was when it was written.

这篇关于db4o体验?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆