Oracle最近向SQLite发布了Berkeley DB后端.我碰巧有一个数百兆字节的SQLite数据库,可以从"改进的性能,并发性,可伸缩性和可靠性"中获益,但Oracle的网站似乎缺乏对这些改进的任何测量.有没有人在这里做过一些基准测试？
我参与了BDB SQLite代码的beta评估,我尝试处理的一个问题是性能差异.在这一点上,我无法准确发布我发现的内容,直到我至少有一个人评估我的代码,运行测试,并确认我得到的数字(正在完成).但是,我可以概括一下,并说有些情况下BDB提供了超过SQLite的显着性能改进,特别是在处理涉及写并发的重负载方面.
一般来说,有两种"快速"权利衡量标准 - (1)效率:单个流程执行XYZ需要多长时间？(2)并发性:每单位时间内多个流程执行XYZ的次数.BDB解决的主要问题是并发 - 大规模事务处理.因此,您会想到许多并发连接写入和/或修改数据库的内容.
SQLite by design使用数据库级锁定,因此最多只能有一个编写器一次在数据库中工作.因此,SQLite的事务率随着并发连接的数量或多或少保持不变,因此它在写密集型应用程序中的可伸缩性实际上是通过其效率来衡量的(1).
另一方面,BDB使用页面级锁定,这允许多个编写器在给定时间在数据库中工作(假设它们在不同的页面上工作).因此,BDB的速率可能会随着连接数的增加而增加,因此它的可扩展性既是效率(1),也是并发(2),可以加起来.
主要是它归结为(写)并发.对于多个编写者,BDB可以比SQLite推送更多的TPS.通过事务,我的意思是修改数据库(它们对于只读操作有什么实际帮助？).也就是说,对于读并发(主要执行SELECT的应用程序),SQLite很可能与BDB直接对抗,因为锁定不再是一个关键问题.
至于数据集的大小,我不确定.我没有调查过.最终,他们都使用B树存储.他们各自的实现中可能有一些因素需要考虑,但我没有对此进行调查.我知道的SQLite可以从容地处理数据集到数百MB的和两位数的绿带(也许还有更多,现在脏页地图执行已更改)的.
因此,如果您的应用程序使用许多连接来修改给定的数据库并且页面争用相对较低,那么BDB可以提供显着的性能改进.但页面争用是一个关键变量.在极限情况下,如果你有一个BDB数据库,其数据由一个单页的,那么它的性能将匹配的SQLite在所有情况下,因为页级锁在这里有效地退化为数据库级锁相当于 - 大家都在争夺一件事.然而,随着网页数量在增加BDB(和页面争降低),则最大TPS将开始与并发连接数增长.然后从那时起,记忆成为下一个限制因素.但这是另一个故事.
顺便说一句,我正在写一篇关于为来自SQLite的人使用BDB的文章.
文章链接:
Oracle Berkeley DB SQL API与SQLite API - 技术评估
Oracle Berkeley DB SQL API与SQLite API - 集成,优势和差异
这有点像一个问题.根据您的磁盘访问速度,内存中缓存的大小,插入与读取的数量,页面拆分,并发等等,结果会有很大差异.
总体而言,BerkeleyDB 可以非常快 - 我最近为雇主设计了一个内置的数据分析平台,该平台能够在8核x86系统上每秒进行40k次插入(同时每秒进行数千次读取) 30G范围内的数据集.这是完全的事务保护.
但这是最好的情况 - 有时插入可能会降至每秒2k,这取决于传入的数据以及当前存储在Berkeley中的数据.如果磁盘I/O速度较慢且缓存命中率较低,或者不断扩展数据库导致页面拆分,则性能会显着下降.您还可以进行大量调整以提高特定数据集的性能.
总的来说,这是一个优秀的系统,但文档和知识相当渺茫.我推荐The BerkeleyDB Book可能是目前最好的参考书.
除了Brian提到的Berkeley DB Book之外,您还可以找到以下有用的资源:
Berkeley DB在线论坛可以提供用户和产品开发人员的大量建议.请参阅Berkeley DB论坛,
Berkeley DB文档集,可在此处找到.特别是,参考指南中有几个部分涉及调整,性能和吞吐量.
京公网安备 11010802040832号 | 京ICP备19059560号-6 