ObjectDB 生产准备好了吗？
在此基准测试中，ObjectDB 是最快的数据库： http://www.jpab.org/All/All/All.html
但我看不到 ObjectDB 的任何其他基准测试结果。 有人用ObjectDB吗？生产准备好了吗？有哪些经验？
In this benchmark ObjectDB is far the fastest DB:
http://www.jpab.org/All/All/All.html
But I cannot see any other benchmark results from ObjectDB.
Is anyone using ObjectDB? Is it production ready? What are the experiences?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我已经将它用于许多项目和产品，无论是专业的还是个人的。我已经使用它 5 年多了。以下是我的经验：
免责声明：我拥有服务器许可证和 OEM 许可证，多年来已经了解了创建者。我与 ObjectDB 公司没有其他商业关系 - 换句话说，如果他们销售更多副本，我就不会获得任何商业利益。我只是喜欢这个产品。
我的用法：
就我个人而言：我将它用作我的博士毕业的商业产品的一部分，以保留 UML2/EMF 模型。这些都是复杂的事情，有很多很多类，ObjectDB 是我能找到的唯一能够以足够的性能处理复杂链接的产品。它在这种环境中表现出色。
工作相关：我在一家投资银行工作，我们使用 ObjectDB 来保存工作流状态并处理大型网格（>2000 个节点）环境中的持久性。它在这种环境中也运行得很好。
大约在 2007 年左右，我曾担任 Gentleware 的顾问，我们针对 db4o、hibernate 等评估了 ObjectDB。它的性能比任何竞争对手都高出近一个数量级。这是我第一次使用它进行商业体验。
所以，最重要的是，我发现 ObjectDB 非常快，而且坚如磐石。我们在 UML2 模型上单独测试了高达 10GB 的容量，没有出现任何问题。在我使用数据库的所有时间里，我从未遇到过数据库死机或损坏的情况。此外，它的占地面积非常小。简而言之，它有点像这个领域的无名英雄。
我的经验与 jpab 基准一致 - 它们让其他产品的所有者阅读起来感到不舒服，但是......也许我在这方面并不完全公正 - 我与 ObjectDB 的创建者有过很多接触多年并推动他们发布基准。特别是，我觉得他们应该使图表成为线性而不是对数 - 它表明 ObjectDB 的性能在大多数情况下要好得多。
顺便说一句，您在该产品或任何其他 JPA 产品上找不到许多其他基准的原因是，没有一个供应商能够普遍就基准达成一致，并且倾向于指责其他供应商存在偏见。我已经亲眼目睹过很多次了。有些人更喜欢 pollos，但这由 db4o 主导，并且这些人不会发布 dn 结果等。一些数据库供应商不允许结果等。这是一个雷区，ObjectDB 的创建者在这里也不例外。每个人都喜欢控制自己的基准;-)
无论如何，长话短说，我的诚实经验是 ObjectDB 非常快，可以用于生产（多年来一直回到 1.x）并且得到良好的支持。这是一个非常好的产品。
I've used it for a number of projects and products, both professionally and personally. I've used it for a little over 5 years now. These are my experiences of it:
Disclaimer: I own a server license and an OEM license, and over the years have got to know the creator(s). I have no other commercial relationship with the ObjectDB company - in other words, I gain nothing commercially if they sell more copies. I just like the product.
My usages:
personally: I used it as part of a commercial product that came out of my phd, to persist UML2/EMF models. these are complex things with many, many classes and ObjectDB was the only product i was able to find that could handle the complex linking with adequate performance. it has been a stellar performer in this environment.
work related: I work in an investment bank and we used ObjectDB to persist the workflow states and handle persistence in a large grid (>2000 nodes) environment. It worked very well in this environment as well.
I was also a consultant to Gentleware at one point back in 2007 or so, and we evaluated ObjectDB against db4o, hibernate etc. It outperformed any competition by close to an order of magnitude. This was my first commercial experience with it.
So, the bottom line is that I have found ObjectDB to be extremely fast, and rock solid. We tested it up to 10GB alone on the UML2 models and there were no problems there. I've never had a database die on me or get corrupted in all my time of using it. Furthermore, its footprint is pretty small. In short, it's a bit of an unsung hero in the space.
My experiences concur with the jpab benchmarks - they make uncomfortable reading for the owners of other products, but... perhaps i'm not completely unbiased in this though - i've had much contact with the creator(s) of ObjectDB over the years and pushed them to release the benchmarks. in particular, i felt they should make the graph linear rather than logarithmic - it shows the performance of ObjectDB is vastly better in most cases.
As an aside, the reason why you won't find many other benchmarks on this or any other JPA product is that none of the vendors can generally agree on a benchmark and tend to accuse others of bias. I've seen this first hand many times. Some people prefer polepos, but this is dominated by db4o and those people won't release the dn results for instance. Some database vendors won't allow results etc. It's a minefield and the creators of ObjectDB are no different here. Everyone likes to control their own benchmark ;-)
anyway, to cut a long story short, my honest experience is that ObjectDB is very quick, production ready (for a number of years back to 1.x) and well supported. It's a very good product.
我们在初创公司中使用对象数据库已经有 5 个多月了。在研究了不同的技术（RDBMS、Graph db 和 object db）之后，我们犹豫了很长时间才选择 objectDB。我们正在开发一个基于 Web 的业务应用程序，并且我们对持久层有一系列要求。我们考虑的其中包括：
MySQL、PostgreSQL、Derby、Db4o、ObjectivityDB、Perst、Ozone、Neadatis ODB、Neo4j、OrientDB
我们的要求是：
ObjectDB 超过 6
岁 – 在我们所说的 2.2.9 版本中
我们希望确保
如果我们遇到问题，有人可以提供帮助，到目前为止我们很高兴
我们获得问题答案的速度。社区可能更大，但非常活跃。
敏捷性和快速功能
对象数据库的周转非常简单和直接
向前。我们考虑过 RDBMS + Hybernate，但这很慢而且
有点复杂
这里没有任何科学依据，但我们
希望系统能够处理大量的数据
并发请求数。我们测试了最多1000个并发
请求、索引查询、对象更新、创建和的组合
删除和集合更新以尝试模拟我们应用程序上的负载。
ObjectDB 名列前 2
同样，我们使用相同类型的查询并对它们进行计时，
我们还增加了我们认为的负载
对我们的帖子进行实时加载和再次使用 ObjectDB 的合理猜测是
一直处于前2名
我们逐渐增加
我们数据库中的客户数量达到 500 万个客户（这是
不太乐观），每个订单有 1 到 5 个，并检查了
表现。没有显着的性能下降（随着
正确的索引到位！）
无法访问的小问题
源，因为我们使用 GWT，它有时会导致问题
托管集合和日期的序列化（尽管有一种解决方法
存在）
如果可能的话，我们希望 JPA 或 JDO 支持能够轻松实现
与现有框架（Spring）集成并放心
最坏的情况下我们仍然可以回到旧的 RDMS 系统 –
虽然我不得不说对象持久化是如此简单
透明的是有时很难坚持 JPA
要求。
总而言之，ObjectDB 一直是我们的前 2 名参赛者，有时是第一，有时是第二，因此我们选择了它。此外，错误修复和新功能发布的频率也令人印象深刻。
我希望这会有所帮助，如果我在上线之前（明年初）有时间将我们的结果以合适的格式呈现，我会尝试将其发布在这里。
We have been using Object DB in our startup for a little over 5 months. We hesitated a long time before settling for objectDB after looking at different technologies (RDBMS, Graph db and object db). We are developing a web based business application and we had a set of requirements for our persistence layer. We considered amongst others :
MySQL, PostgreSQL, Derby, Db4o, ObjectivityDB, Perst, Ozone, Neadatis ODB, Neo4j, OrientDB
Our requirements were:
ObjectDB is more than 6
years old – In version 2.2.9 as we speak
We wanted to make sure there is
someone to help if we have a problem and so far we are very happy
with the speed at which we get answers to our questions. The community could be larger but is very active.
For agility and fast functionality
turnaround an object database is incredibly easy and straight
forward. We considered RDBMS + Hybernate but that was slow and a
little convoluted
Nothing scientific here but we
wanted to feel comfortable that the system could handle a large
number of concurrent requests. We tested up to 1000 concurrent
requests, a mix of indexed queries, object updates, creations and
deletions and collection updates to try and mimic load on our app.
ObjectDB came out in the top 2
Same here we used the same type of queries and timed them,
we also increased the load to what we think is going to be a
reasonable guess of our post go live load and again ObjectDB was
constantly in the top 2
We gradually increased
the number of customers in our DB to 5 million customers (that’s a
little optimistic) with 1 to 5 orders each and checked the
performance. There was no significant performance decrease (with the
right indexes in place!)
Small issue with not having access to the
source as we are using GWT and it sometimes causes issues with
serialisation of managed collections and dates (although a workaround
exists)
If possible we wanted JPA or JDO support to easily
integrate with existing frameworks (Spring) and be reassured that
worst comes to worst we can still go back to an old RDMS systems –
although I have to say that object persistence is so easy and
transparent that it is sometimes hard to stick to the JPA
requirements.
All in all, ObjectDB was constantly in our top 2 contestants, sometimes first, sometimes second hence our choice. Also the frequency of bug fix and new feature releases is impressive.
I hope this helps, if I have sometime before our go live (early next year) to put our results in a presentable format I will try and post them here.
如果没有独立验证，我不会相信该基准。如果你检查一下版权信息，该网站实际上是由ObjectDB的所有者拥有和运营的！
也就是说，我没有数据来反驳他们的说法，我只是不相信他们的表面价值。
I'd not trust that benchmark without independent verification. If you check the copyright information, the site is actually owned and operated by the owners of ObjectDB!
That said, I've no data to counter their claims, I'd just not take them at face value.
我也已经以商业身份使用 ObjectDB 多年（我想有 7 年了）。我们公司有两款使用该数据库的产品（均为嵌入式版本）。我们的一款产品显示有关移动设备（即移动电话）和模拟网络之间发送的信号的信息。尽管我们实际上为运行的每个测试创建了一个单独的数据库，但我们通常可以将最多 1GB 的等效 XML 数据保存到数据库中。
保存数据的速度非常快（通常比要求 Windows 复制等效的 XML 文件要快）。检索速度非常快，使我们能够滚动浏览数千（甚至数万）个图形表示的项目，就像滚动浏览 Windows 资源管理器文件目录一样。
ObjectDB 是一款优秀的产品，我希望继续使用它。当我们开发产品时，我们遇到了奇怪的问题（尽管从我记事起我们就不需要报告任何事情），但我们解决每个问题的速度是我最好的。曾经遇到过。
很好地回答你“这部作品准备好了吗”的问题，在我看来，它肯定是准备好了。
I have also have been using ObjectDB for many years (I think 7 years) in a commercial capacity. Our company has two products that use the database (both embedded version). One of our products displays information about the signals sent between mobile devices (ie mobile phones) and a simulated network. Although we in effect create a separate database for each test that we run we can often save up to 1GB of equivalent XML data into the database.
The speeds for saving the data are very quick (normally faster than asking Windows to make a copy the equivalent XML file). The retrieval speed is excellent allowing us to scroll through thousands (even tens of thousands) of graphically represented items as if scrolling through a Windows explorer file directory.
ObjectDB is an excellent product and one I hope to continue to work with. When we were developing our products we encountered the odd problem (although we've not had to report a single thing for as long as I can remember) but the speed with which we have had a resolution to every problem has been the best I've ever encountered.
To answer you question of "Is this production ready" well, in my opinion, it most certainly is.
我正在一个小项目上测试 ObjectDB。以下是我的评论：
与相同项目的 Versant DB 相比，ObjectDB 上手更简单。
I'm testing ObjectDB on a small project. Here are my remarks:
Compared to Versant DB with the same project and ObjectDB is more straightforward for getting started.
标准行业基准是
http://www.spec.org/jEnterprise2010/ ，
它大量使用 JPA
请注意，它测试整个 Java EE 服务器，而不仅仅是 JPA，但 JPA 是基准测试中最重要的部分。主要的JPA产品都通过各自的应用服务器提交了结果。
SpecJ 不像 JPAB 结果那样容易比较产品，因为大多数结果都在不同的硬件上，但结果都是经过同行评审的，因此可以更可信。它也是一个模拟的真实应用程序，具有多个用户、大型数据库、并发和隔离要求，并且大多数结果都在集群上。
没有可用的 ObjectDB 结果，但理论上由于 ObjectDB 支持 JPA，因此应该可以在其上运行 SpecJ，并自行将其与其他产品进行比较。
The standard industry benchmark is,
http://www.spec.org/jEnterprise2010/
which heavily uses JPA
Note, that it tests the entire Java EE server, not just JPA, but JPA is the most significant part of the benchmark. The main JPA products have submitted results through their respective application servers.
SpecJ is not as easy to compare products as the JPAB results, as most results are on different hardware, but the results are all peer reviewed, so can be more trusted. It is also a simulated real application, with multiple users, a large database, concurrency and isolation requirements and most results are on a cluster.
There are no ObjectDB results available, but in theory since ObjectDB supports JPA it should be possible to run SpecJ on it, and compare it to other products yourself.
更重要的是，数据是一回事，解释又是另一回事。对于为什么它应该快一个数量级，确实缺少一个解释。这一点，以及他们网站上显示的基准测试数量非常低，因此只显示整个图片的一小部分这一事实，对我来说似乎很奇怪。
我的经验（一般来说，不是使用 ObjectDB）是，例如，hibernate 取决于工作负载类型，并且，如果您需要迁移数据库，则需要显式调整 hibernate 行为以获得不错的性能。 ObjectDB支持缓存吗？它是否只在垃圾缓存的大吞吐量场景中表现出色？
更新
我刚刚读过 http://www.objectdb.com/database/forum/259。你猜怎么着，速度的典型克星是一致性。看来ObjectDB根本不支持任何合理的并发模型。那么，它基本上只是一个 NoSQL 存储？
Even more importantly, data is one thing, explanations another one. And there really is an explanation missing as to why it should be faster by a magnitude. This, and the fact that the benchmarks shown on their website are VERY low in count and therefore only show a VERY small part of the entire picture, seems very strange to me.
My experience (in general, not with ObjectDB) is that, for example, hibernate depends on work load type, and, if you need to migrate a database, you need to explicitly adjust hibernate behavior to get a decent performance. Does ObjectDB support caching? Does it only excel in large throughput scenarios that trash caches?
Update
I just read http://www.objectdb.com/database/forum/259. The typical nemesis for speed is, guess what, consistency. It seems ObjectDB does not support any reasonable concurrency model at all. So, it's basically just a NoSQL store?
我已经使用 ObjectDb 10 年了，并且对它非常满意。
诚然，我的数据库相对较小，但我从不断被休眠升级问题绊倒到不必担心它，这多年来为我节省了大量时间。
I have used ObjectDb for 10 years and have been very happy with it.
Admittedly, my database is relatively small, but I went from constantly tripping over hibernate upgrade issues to just not having to worry about it, which has saved me tons of time over the years.