Firebird 2.5 VS Interbase 9 / XE - 哪个性能更快？ [英] Firebird 2.5 VS Interbase 9/XE - which performing faster?

问题描述

我们正处于一种情况，我们必须在thoose 2数据库之间进行选择。
我们目前使用的是Firebird，但有时它会滞后，因为它堆叠了太多的事务历史或事物，并且应该使用备份恢复以使事情更好。

在我的具体情况下：
数据库主要有填充数字字段的表。
查询中主要有内部联接。
几乎相同的速率，我插入，并选择。
（但是在未来我正在寻找更严重的选择）
有3个主表有几十亿条记录（每秒持续增长）。

但我想看看哪个是最好的整体进入如上所述的正常负载，和重载 - 像选择和工作在选定的字段，整体的事件触发和存储过程执行，我认为是足够好的

我要求

• 与Interbase是一样的吗？


• 是否值得向Interbase跳？

<

b
$ b

也许会有人在正常的，每一天的查询基础上实际上数据库的实现，并且问题和结果将对我和其他人都更加有用。

解决方案

您描述的问题通常是由错误的事务管理或长时间运行的事务引起的。一般来说，你不需要备份和恢复来解决这个问题。备份应该是足够的（因为Firebird在备份期间做额外的清理和垃圾回收）。

Firebird（和Interbase）都使用多版本并发控制，记录在新的记录版本。旧记录版本仅在没有对该事务感兴趣的事务打开时清除。

错误的事务管理（具有长时间运行的事务，或使用提交保留而不是提交） ，意外的断开连接等可能意味着事务仍然打开，这意味着他们将需要被数据库清理（在Firebird中所谓的扫描）。这可能会减慢您的数据库，因为它需要读取同一记录的多个版本。

如上所述，执行备份时执行扫描。因此，只是做一个备份应该足以消除大部分的问题。

有关更多详细信息，请参阅 gfix内务管理

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.

解决方案

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

这篇关于Firebird 2.5 VS Interbase 9 / XE - 哪个性能更快？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！