6

我们处于必须在这两个数据库之间进行选择的情况。我们目前在 Firebird 上，但有时它会因为堆积太多的交易历史或其他东西而滞后，应应用备份恢复以使事情变得更好。

在我的具体情况下：数据库的大部分表格都填充了数字字段。查询主要有内部连接。我插入和选择的速度几乎相同。（但在未来我正在寻找更严格的选择）有 3 个主表，其中有数十亿条记录（每秒不断增长）。

但是我想看看在上述正常负载和重载中哪个是最好的，比如选择和处理选定的字段，在事件触发和存储过程执行中的整体性能，我认为这些知识足以选择他们之间（欢迎更多意见）并且可能会帮助其他人做出决定。

我在问

  • 和 Interbase 一样吗？
  • 是否值得向 Interbase 努力？
  • 哪个整体表现更好？
  • Interbase 是否有像 Firebird 这样的历史问题，它会不断增长数据库并减慢它的速度？

PS：我将暂时离开这个问题而不检查解决方案。也许会有人比较实际的数据库，每天的查询库，问题和结果对我和其他人来说会更有用。

4

3 回答 3

8

您描述的问题通常是由糟糕的事务管理或长时间运行的事务引起的。通常，您不需要备份和恢复来解决此问题。备份就足够了（因为 Firebird 在备份期间会进行额外的清理和垃圾收集）。

Firebird（和 Interbase）都使用多版本并发控制，这意味着更改记录在新的记录版本中。仅当没有对该交易感兴趣的交易打开时，才会清理旧的记录版本。由回滚事务创建的记录版本仅在扫描期间被清除。

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

如前所述，在进行备份时执行扫描。因此，只需进行备份就足以消除大部分问题。

有关更多详细信息，请查看gfix housekeeping

于 2011-05-27T10:04:37.323 回答
7

显而易见且恐怕相当乏味的答案是，您将不得不使用自己的工作负载对两者进行基准测试。您的应用程序工作负载可能与其他所有基准测试或应用程序不同。

于 2011-05-26T07:22:49.983 回答
3

您可以将测试数据库和测试用例发送给 Firebird 开发人员，以便他们提高速度

我开始认为数据库需要分区

于 2011-05-31T08:46:28.810 回答