我正在与另一位开发人员建立一个项目，这是一位非常有经验和能力的编码员，他的技能和能力都没有问题。最近我给他发了一个我做过的一些工作的演示，他似乎有点惊讶我选择了一个Firebird数据库。谈话是这样的：
他：你为什么选择火鸟？ SQLite会更快。
我：SQLite只是嵌入式的，并且不能很好地扩展。此外，它缺少很多功能，包括存储过程支持。
他：当您的数据库大小超出可用RAM的数量时，Firebird也存在可伸缩性问题。
我：你是什么意思？
他（直接引用他的电子邮件）：大规模减速。显然当索引+数据不适合RAM（物理RAM，而不是虚拟RAM）时，它会进入各种类型的“慢速模式”，我们已经能够通过增加FireBird conf的内存使用值来在一定程度上缓解它但是，如果由于某种原因它无法获取内存（与MSSQL或MySQL fi相反，FireBird在启动时不会保留物理RAM，只是逐步），则存在突然“内存不足”故障的风险。即使在24 GB的机器上，在8 GB以上的情况下，无论内存如何，减速似乎都会保持不变。所以我们逐步将它们迁移到Oracle / MSSQL。
正如我所说，这是一个非常聪明，有能力的开发人员。但另一方面，我们有Firebird网站声称people are using it in production for databases over 11 TB in size，如果他说的是真的，那么对于所有意图和目的来说，这是不切实际的，这是不切实际的。
所以我不得不怀疑，这个问题确实存在于Firebird中，还是他忽略了某些东西，也许是他不知道的一些配置选项？是否有人熟悉他所描述的问题？
答案 0 :(得分：5)
正如我之前评论的那样，其他开发人员所描述的内容可归因于Windows 64位上的Windows文件系统缓存与Firebird使用{{1}读取其数据库文件的事实相结合的错误。 }。由于某种原因，这会导致文件系统缓存不从其缓存中释放页面，导致其可能超出可用物理内存（并最终可能超出可用虚拟内存），有关详细信息，请参阅this blog post。此问题已在Firebird 2.1.5和2.5.2中使用CORE-3971修复。
case studies on firebirdsql.org列出了数十或数百或千兆字节的数据库示例，但它们似乎不会遇到性能问题。
一家提供Firebird恢复和性能优化服务的公司曾经test with a 1 terabyte database做了一段时间。该页面还列出了三个相对较大的Firebird数据库示例。
披露：我为Firebird开发了一个数据库驱动程序，所以我可能有点偏见;）