我疯了吗？将现有产品从 HSQLDB 切换到 Apache Derby
我有一个成熟的软件产品，它使用 HSQLDB 作为其内部设置数据库。客户项目存储在该数据库中。多年来，HSQLDB 为我们提供了相当好的服务，但它存在一些稳定性/损坏问题，我们必须围绕这些问题进行编码，即使如此，我们似乎也无法完全保护自己免受这些问题的影响。
我正在考虑更改内部数据库。从开发的角度来看，这样做会相当痛苦，但向客户解释损坏的数据库（和丢失的数据）并不有趣。
所以我的问题是：是否有人有足够的经验来衡量 Apache Derby 的长期稳定性？我通过 Google 发现了一篇帖子，抱怨 Derby 不稳定，但它是 2006 年的，所以我认为它在过去 4 年里已经得到了改进。或者，是否有另一个我可以使用的纯 Java 嵌入式（进程内）数据库（商业或开源）。性能对我来说并不是很重要。稳定才是王道。断电时的数据完整性、良好的 BLOB 支持和热备份都是必须的。
请不要建议不是基于 SQL 的关系数据库的东西。我正在尝试改造现有产品，而不是从头开始，谢谢。
I have an established software product that uses HSQLDB as its internal settings database. Customer projects are stored in this database. Over the years, HSQLDB has served us reasonably well, but it has some stability/corruption issues that we've had to code circles around, and even then, we can't seem to protect ourselves from them completely.
I'm considering changing internal databases. Doing this would be fairly painful from a development perspective, but corrupted databases (and lost data) are not fun to explain to customers.
So my question is: Does anyone have enough experience to weigh in on the long-term stability of Apache Derby? I found a post via Google complaining that Derby was unstable, but it was from 2006 so I'd entertain the idea that it has been improved in the last 4 years. Or, is there another pure Java embedded (in-process) database that I could use (commercial or open-source). Performance isn't very important to me. Stability is king. Data integrity across power loss, good BLOB support, and hot-backups are all a must.
Please don't suggest something that isn't a SQL-based relational database. I'm trying to retrofit an existing product, not start from scratch, thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
如果您正在寻找独立的东西（不涉及服务器），请尝试 SQLite。这就是 Android 的 db api 的支持，并且非常稳定。
Give SQLite a try if you're looking for something self contained (no server involved). This is what backs android's db api, and is highly stable.
对于 HSQLDB，它作为一个项目所没有的一件事是 SQLite 拥有的强大测试套件的文档和严格的 ACID 合规性的在线文档。
我并不是想从 HSQLDB 中拿走任何东西。它的目的是作为 MySQL 的替代品，而不是像 SQLite 那样替代 fopen()。可以说，HSQLDB（实际上是所有 Java RDBMS）的范围要宏大得多。 Fredt 和他的团队利用 HSQLDB 取得了非凡的成就。即便如此，在 Google 上搜索“HSQLDB ACID 是否兼容”并不会让早期采用者像在 SQLite 网站上阅读有关测试工具后那样充满信心。
在 http://sqlite.org/transactional.html 中，
“SQLite 是事务性的
事务性数据库是这样一种数据库：所有更改和查询都是原子的、一致的、隔离的和持久的 (ACID)，即使事务因程序崩溃、操作系统崩溃而中断，SQLite 也实现了原子、一致、隔离和持久的可序列化事务。或计算机电源故障，
我们在此重申并放大前面的句子以强调：SQLite 中单个事务中的所有更改要么完全发生，要么根本不发生，即使将更改写入磁盘的操作被中断。
在 SQLite 回归测试套件中使用特殊的测试工具进行了广泛的检查，该测试工具模拟了操作系统崩溃和电源故障对数据库文件的影响。 ”
在 http://sqlite.org/testing.html
》 1.0 简介
实现了 SQLite 的可靠性和健壮性 。
从版本 3.7.14 开始，SQLite 库由大约 81.3 KSLOC 的 C 代码组成（KSLOC 意味着数千个“源代码行”，或者换句话说，不包括空白行的代码行 和评论。）相比之下，该项目的测试代码和测试脚本是原来的 1124 倍 - 91421.1 KSLOC
1.1 执行摘要
三个独立开发的测试工具。
部署配置中 100% 分支测试覆盖率
数以百万计的测试用例
内存不足测试
I/O 错误测试
碰撞和断电测试
模糊测试
边界值测试
禁用优化测试
回归测试
格式错误的数据库测试
广泛使用assert()和运行时检查
Valgrind 分析
有符号整数溢出检查"
With regard to HSQLDB, one thing that it doesn't have as a project that SQLite has is the documentation of a robust testing suite and online documentation of assiduous ACID compliance.
I don't mean to take anything away from HSQLDB. It's meant to serve as an alternative to MySQL not to fopen() as SQLite is intended. One can say that the scope of HSQLDB (all the Java RDBMS's really) is much more ambiitious. Fredt and his group have accomplished an extraordinary achievement with HSQLDB. Even so, doing the Google search "Is HSQLDB ACID compliant" doesn't leave an early adopter feeling as confident as one feels after reading about the testing harnesses on the SQLite website.
At http://sqlite.org/transactional.html
"SQLite is Transactional
A transactional database is one in which all changes and queries appear to be Atomic, Consistent, Isolated, and Durable (ACID). SQLite implements serializable transactions that are atomic, consistent, isolated, and durable, even if the transaction is interrupted by a program crash, an operating system crash, or a power failure to the computer.
We here restate and amplify the previous sentence for emphasis: All changes within a single transaction in SQLite either occur completely or not at all, even if the act of writing the change out to the disk is interrupted by
The claim of the previous paragraph is extensively checked in the SQLite regression test suite using a special test harness that simulates the effects on a database file of operating system crashes and power failures."
At http://sqlite.org/testing.html
"1.0 Introduction
The reliability and robustness of SQLite is achieved in part by thorough and careful testing.
As of version 3.7.14, the SQLite library consists of approximately 81.3 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 1124 times as much test code and test scripts - 91421.1 KSLOC.
1.1 Executive Summary
Three independently developed test harnesses
100% branch test coverage in an as-deployed configuration
Millions and millions of test cases
Out-of-memory tests
I/O error tests
Crash and power loss tests
Fuzz tests
Boundary value tests
Disabled optimization tests
Regression tests
Malformed database tests
Extensive use of assert() and run-time checks
Valgrind analysis
Signed-integer overflow checks"
尝试查看 H2。它是由最初制作 HSQLDB 的人创建的，但是是从头开始构建的，因此不使用任何 HSQLDB 代码。不确定它的稳定性与 HSQL 相比如何，因为我已经很久没有使用 HSQL 并且目前我只将 H2 用于短期数据库。我个人发现 H2 比 Derby 更容易上手，但也许这是因为 H2 有一个备忘单网页。
可以重新编码以使用抽象层，然后运行测试以将 H2 和 Derby 与您发现的问题进行比较。
在项目管理方面，您的路线图是否有主要版本即将推出？这可能是一个相当合适的时机，以这种方式彻底剖析，我不会说你疯了，因为它可能会消除许多难以管理的变通办法。如果您想在没有充分警告和备份的情况下进行可能影响实时系统的更改，那么您可能会发疯。
Try looking into H2. It was created by the guy who originally made HSQLDB but built from scratch so doesn't use any HSQLDB code. Not sure how its stability compares to HSQL since I haven't used HSQL in ages and I'm only using H2 for short-lived databases currently. I personally found H2 to be easier to get going than Derby but maybe that's because H2 has a cheat sheet web page.
It might be possible to re-code to use an abstraction layer and then run tests to compare H2 and Derby with the issues you have found.
On the project management side of the fence, does your roadmap have a major version coming up? That might be a rather appropriate time to rip out the guts this way and I wouldn't say you were crazy cause it could potentially remove lots of hard to manage work arounds. If you wanted to make the change where it could affect live systems without plenty of warning and backups in place then you may be crazy.
自 2009 年以来，我一直在我的许多项目中使用 Apache Derby，其中一些项目需要 24/7 运行和数百万行。
从未发生过任何数据损坏事件。坚如磐石且快速。
我一直选择它作为我的 RDBMS 选择，除非有充分的理由不跳出来。
I have been using Apache Derby since 2009 in many of my projects, some of them with 24/7 operation and many millions of rows.
Never ever had a single event of data corruption. Rock solid and fast.
I keep choosing it as my RDBMS of choice, unless a good reason not to pops out.
Derby，前 IBM Cloudscape（现在也由 Sun 作为 JavaDB 分发）是一个符合 ACID 的数据库，可以承受大量并发用户，运行嵌入式或服务器模式，并且众所周知是健壮的和生产的准备好。它不如 HSQLDB 快（Derby 使用持久操作），但它很健壮。不过，您应该对其进行自己的测试。
另请参阅
Derby, ex IBM Cloudscape (and now also distributed by Sun as JavaDB) is an ACID-compliant database that can stand a lot of concurrent users, running embedded or in server mode, and is know to be robust and production ready. It is not as fast as HSQLDB (Derby uses durable operations), but it's robust. Still, you should run your own tests against it.
See also
此搜索显示 HSQLDB 用户邮件列表中包含字符串“corrupt”的 215 个帖子。
http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.java.hsqldb.user&sort =date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcomp.java.hsqldb.user---A
此搜索显示 Derby Users 邮件列表中包含相同字符串的 264 个帖子。
http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.apache.db .derby.user&sort=date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcomp.apache.db.derby.user---A
这显示了 Derby Dev 邮件列表中具有相同字符串的 1003 个帖子
http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.apache.db .derby.devel&sort=date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcomp.apache.db.derby.devel---A
看一下一些帖子显示了数据库的可能或真实情况尽管数据库开发人员尽了最大努力，腐败还是发生了。
HSQLDB 也有自己的数据库损坏问题，但多年来已经有所改善。在最新版本中，引入了预防措施和修复措施，以防止过去几年报告的所有问题。
然而，新的 lob 存储功能被证明存在逻辑错误，导致更新后 lob 被“遗忘”。目前正在修复此问题，并通过更广泛的测试来支持修复。
多年来，像 CarlG 这样的用户在 Derby 和 HSQLDB 的错误修复工作中提供了很多帮助。
Fred Toussi，HSQLDB 项目
This search shows 215 posts in HSQLDB Users mailing list containing the string "corrupt".
http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.java.hsqldb.user&sort=date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcomp.java.hsqldb.user---A
This search shows 264 posts in Derby Users mailing list containing the same string.
http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.apache.db.derby.user&sort=date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcomp.apache.db.derby.user---A
This one shows 1003 posts in Derby Dev mailing list with the same string
http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.apache.db.derby.devel&sort=date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcomp.apache.db.derby.devel---A
A look at some of the posts shows possible or real cases of database corruption happen despite all the best efforts of database developers.
HSQLDB has had its own share of database corruption issues but has improved over the years. In the latest versions precautions and fixes have been introduced to prevent all the issues that were reported in the last few years.
The new lob storage feature however, turned out to have a logic bug that results in the lobs being "forgotten" after an update. This is being fixed right now, with more extensive tests to support the fix.
Users like CarlG have helped a lot over the years in the bug fixing efforts of both Derby and HSQLDB.
Fred Toussi, HSQLDB Project
我将 Derby 24/7 作为支持构建自动化和测试管理系统的内部数据库运行了 4 年。它被全球团队使用，从未崩溃、丢失数据或损坏我的记录。我们停止使用它的唯一原因是因为我们的公司被另一家公司收购了，并且下达了更高层的决定。 Derby 坚固、可靠，非常值得您考虑。
I ran Derby 24/7 as the internal database supporting a build automation and test management system for 4 years. It was used by a worldwide team, and never crashed, lost data, or corrupted my records. The only reason we stopped using it is because our company was bought by another and a higher-level decision was handed down. Derby is solid, reliable, and well worth your consideration.
对于每个数据库引擎都存在一定的损坏风险。我是H2数据库的主要作者，我也收到过有关数据库损坏的报告。测试可以减少出现错误的可能性，但不幸的是，几乎不可能保证某些软件“没有错误”。
至于HSQLDB、Apache Derby、H2这三个Java数据库，我实在不好说哪一个最稳定。我只能谈谈H2。我认为对于大多数操作来说，H2 现在是稳定的。有许多测试用例专门测试数据库是否损坏。这包括断电自动测试（使用圣诞灯定时器）。通过电源故障测试，我发现稳定性还取决于文件系统：有时我会收到“CRC 错误”消息，这意味着操作系统无法读取文件（它是 Windows）。在这种情况下，您无能为力。
对于关键任务数据，无论如何我都不会依赖软件的稳定性。定期创建备份并进行测试非常重要。有些数据库有多种方式来创建备份。例如H2具有在线备份功能，以及编写SQL脚本文件的功能。另一种方法是使用复制或集群。 H2支持简单的集群模式，相信Derby支持复制。
For each database engine there is a certain risk of corruption. I am the main author of the H2 database, and I also got reports about broken databases. Testing can reduce the probability of bugs, but unfortunately it's almost impossible to guarantee some software is 'bug free'.
As for the three Java database HSQLDB, Apache Derby, and H2, I can't really say which one is the most stable. I can only speak about H2. I think for most operations, H2 is now stable. There are many test cases that specially test for databases getting corrupt. This includes automated tests on power loss (using a christmas light timer). With power failure tests I found out stability also depends on the file system: sometimes I got 'CRC error' messages meaning the operating system can't read the file (it was Windows). In that case, there is not much you can do.
For mission critical data, in any case I wouldn't rely on the software being stable. It's very important to create backups regularly, and test them. Some databases have multiple way to create backups. H2 for example has an online backup feature, and a feature to write a SQL script file. An alternative is to use replication or clustering. H2 supports a simple cluster mode, I believe Derby supports replication.