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