Berkeley DB SQL与SQLite相比有多快?

时间:2010-05-13 02:36:24

标签: sqlite benchmarking berkeley-db

Oracle最近发布了a Berkeley DB back-end to SQLite。我碰巧有一个数百兆字节的SQLite数据库,它可以从“改进的性能,并发性,可伸缩性和可靠性”中获益,但Oracle的网站似乎缺乏任何测量的改进。有没有人在这里做过一些基准测试?

3 个答案:

答案 0 :(得分:56)

我参与了BDB SQLite代码的beta评估和其中一个 我试图掌握的是性能差异。在此刻, 在我至少有一个人之前,我无法准确地发布我发现的内容 评估我的代码,运行测试,并确认我得到的数字(正在 完成)。但是,我可以在这里概括并说有BDB的情况 提供了超过SQLite的显着性能改进,特别是在 处理涉及写并发的重负载的区域。

一般来说,有两种“快速”权利的衡量标准 - (1)效率:多长时间 是否需要单个进程才能执行XYZ与(2)并发:多少次 可以在很多进程中每单位时间执行XYZ。 BDB解决的主要问题是 并发 - 大规模事务处理。因此你会想到很多 并发连接写入和/或修改数据库的内容。

SQLite by design使用数据库级锁定,因此最多只有一个 可以一次在数据库中工作的作家。因此,SQLite的交易 因为并发连接的数量,速率或多或少保持不变 它在写密集型应用程序中的可扩展性实际上是由它来衡量的 效率(1)。

另一方面,BDB使用页面级锁定,允许多个编写器 在给定时间在数据库中工作(假设他们正在努力 单独的页面)。因此,BDB的比率可能会随着数量的增加而增加 连接,因此它的可扩展性是效率问题(1)和 并发(2),可以加起来。

主要归结为(写)并发。 BDB可以推动更多的TPS 适用于多个编写者的SQLite。通过交易,我的意思是修改了 数据库(它们如何对只读操作有任何实际帮助?)。那说, 对于读并发(主要执行SELECT的应用程序),SQLite很可能会去 与BDB对决,因为锁定不再是一个关键问题。

至于数据集的大小,我不确定。我没有调查过 那。最终,他们都使用B树存储。可能有因素 他们各自的实现要考虑,但我没有调查过。一世 知道SQLite可以优雅地处理数百MB的数据集 两位数的GB(现在可能更多的是脏页面映射实现 已经改变了。)

因此,如果您有一个应用程序,它使用许多修改的连接 给定的数据库和页面争用相对较低,然后BDB可以提供 显着的性能改进。但页面争用是至关重要的 变量。在限制中,如果您有一个BDB数据库,其数据由一个 单页,然后它的性能将在所有情况下与SQLite的性能相匹配 因为这里的页面级锁定有效地退化为相当于 数据库级别锁定 - 每个人都在争夺一件事。但是,作为 BDB中的页数增加(并且页面争用减少),然后是 最大TPS将随着并发连接数的增加而增长。然后 从那时起,记忆成为下一个限制因素。但那是另一回事 故事。

顺便说一下,我正在写一篇关于为即将到来的人使用BDB的文章 来自SQLite。

文章链接:

Oracle Berkeley DB SQL API vs. SQLite API – A Technical Evaluation

Oracle Berkeley DB SQL API vs. SQLite API – Integration, Benefits and Differences

答案 1 :(得分:11)

这有点问题。根据您的磁盘访问速度,内存中缓存的大小,插入与读取的数量,页面拆分,并发等等,结果会有很大差异。

总的来说,BerkeleyDB 可以非常快 - 我最近为雇主设计了一个内置的数据分析平台,该平台能够在8核x86系统上每秒进行40k次插入(同时在同一时间)使用30G范围内的数据集,每秒进行数千次读取。这是完全的事务保护。

尽管如此,这是最好的情况 - 有时候插入可能会降低到每秒2k,这取决于传入的数据以及当前存储在Berkeley中的数据。如果磁盘I / O速度较慢且缓存命中率较低,或者不断扩展数据库导致页面拆分,则性能会显着下降。您还可以进行大量调整以提高特定数据集的性能。

总体而言,这是一个优秀的系统,但文档和知识相当渺茫。我建议The BerkeleyDB Book可能是目前最好的参考资料。

答案 2 :(得分:7)

除了Brian提到的Berkeley DB Book之外,您还可以找到以下资源:

  • Berkeley DB在线论坛可以提供用户和产品开发人员的大量建议。见Berkeley DB forum
  • Berkeley DB文档集,可以找到here。特别是,参考指南中有几个部分涉及调整,性能和吞吐量。