Firebird 2.5 VS Interbase 9/XE - 哪个性能更快？
我们面临的情况是必须在这两个数据库之间进行选择。 我们目前使用 Firebird，但有时它会因为堆积太多事务历史记录或其他原因而滞后，并且应应用备份恢复以使事情变得更好。
就我的具体情况而言： 数据库中大部分表格都填充了数字字段。 查询大多有内部联接。 我插入和选择的速率几乎相同。 （但在未来我正在考虑更严格的选择） 有 3 个主表，有数十亿条记录（每秒不断增长）。
但我想看看哪一个对于像上面那样的正常负载和重载来说是最好的 - 比如选择和处理选定的字段，事件触发和存储过程执行的整体性能，我认为这些知识足以选择他们之间（欢迎更多意见）可能会帮助其他人做出决定。
我想问一下
- Interbase 是一样的吗？
- 值得付出努力转向 Interbase 吗？
- 哪个整体表现更好？
- Interbase 是否也有像 Firebird 这样的历史问题，它会不断增长数据库并减慢速度？
PS：我暂时不检查解决方案而留下这个问题。也许会有人根据正常的日常查询来实际比较数据库，并且问题和结果对我和其他遇到这种情况的人来说会更有用。
We are on a situation where we must choose between thoose 2 databases.
We are currently on Firebird, but sometime it lag because of it stacking too much transaction history or something and backup-restore shall be applied in order to make things better.
In my specific case:
Database have mostly tables filled with numeric fields.
There is mostly inner joins on the queries.
Almost the same rate i am inserting, and selecting.
( but on future i am looking about more severe selecting )
There is 3 main tables which having a few bilions of records ( keep growing each second ).
But i would like to see which is the best overall into normal loads like thoose above, and overloads - like selecting and working on the selected fields, preformance overall into event trigering and store procedure execution which i am thinking is sufficient good enought knowlege to choose between them ( more opinions is welcome ) and probably will help other peoples to took the descision.
I am asking
- is it the same with Interbase ?
- Is it worth the effort of jumping toward Interbase ?
- Which performing better overall ?
- Is Interbase having this history issue like Firebird, which keep growing database, and slowing it down ?
P.S.: I will leave this question without check for a solution for now. Maybe there will be someone to comare actually the databases on normal, each-day querys base, and the question and results will be more usable for me and the other peoples falled on such situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您描述的问题通常是由不良的事务管理或长时间运行的事务引起的。一般来说，您不需要备份和恢复来解决此问题。备份应该足够了（因为 Firebird 在备份期间会进行额外的清理和垃圾收集）。
Firebird（和Interbase）都使用多版本并发控制，这意味着更改会记录在新的记录版本中。仅当没有打开对该事务感兴趣的事务时，旧记录版本才会被清除。由回滚事务创建的记录版本仅在扫描期间清除。
糟糕的事务管理（事务长时间运行，或者使用提交保留而不是提交）、意外断开连接等可能意味着事务仍然处于打开状态，这意味着它们需要由数据库清理（Firebird 中所谓的清理） ）。这可能会减慢数据库的速度，因为它需要读取同一记录的多个版本。
如前所述，扫描是在进行备份时执行的。因此，只需进行备份就足以消除大多数问题。
有关更多详细信息，请参阅 gfix housekeeping
The problem you describe is usually caused by bad transaction management, or long running transactions. In general you don't need a backup and restore to fix this. A backup should be sufficient (as Firebird does extra clean up and garbage collection during backup).
Firebird (and Interbase) both use Multi Version Concurrency Control, meaning that changes are recorded in a new record version. Old record versions are only cleaned up when there are no transactions open that have an interest in that transaction. Record versions that were created by a rolled back transaction is only cleaned up during a sweep.
Bad transaction management (having long running transactions, or using commit retaining instead of commit), unexpected disconnects, etc can mean that transactions are still open, which means that they will need to be cleaned up by the database (a so called sweep in Firebird). This can slow down your database because it needs to read multiple versions of the same record.
As said, the sweep is performed when doing a backup. So just doing a backup should be sufficient to remove most of the problems.
For more detailed information, look at gfix housekeeping
显而易见且恐怕相当乏味的答案是，您将必须使用自己的工作负载对两者进行基准测试。您的应用程序工作负载很可能与其他基准测试或应用程序不同。
The obvious and I'm afraid rather tedious answer is that you are going to have to benchmark the two using your own workloads. The chances are that your applications workloads will be different from every other benchmark or application.
您可以将测试数据库和测试用例发送给 Firebird 开发人员，以便他们可以提高速度
我开始认为数据库需要分区
You can send the test databases and the test case to the Firebird developers so they can improve the speed
I start to think that database needs partitioning