与SQLite相比,Berkeley DB SQL有多快?

我参与了BDB-SQLite代码的beta评估和 我试图处理的是性能差异。在这一点上, 评估我的代码,运行测试,并确认我得到的数字(这是 比SQLite提供了显著的性能改进,特别是在 处理涉及写并发的重负载的领域。

许多进程可以每单位时间执行XYZ。BDB地址的主要问题是 并发——大规模事务处理。所以你想到了很多

SQLite在设计上使用数据库级锁定,因此最多有一个 速率与并发连接的数量大致保持不变,因此 它在写密集型应用程序中的可伸缩性实际上是由它的 效率(1)。

另一方面,BDB使用页面级锁定,这允许多个writer 在给定的时间在数据库中工作(前提是他们正在 因此,它的可伸缩性是一个效率问题(1)和 并发性(2),可以加起来。

主要归结为(写)并发。BDB可以推动更多的测试程序集 多个编写器的SQLite。我所说的交易,是指改变 数据库(它们对只读操作有什么真正的帮助?)。也就是说, 与BDB正面交锋,因为锁定不再是关键问题。

至于数据集的大小,我不确定。我没有调查过 那个。最终,它们都使用B-树作为存储。这里面可能有一些因素 它们各自的实现需要考虑,但我没有对此进行调查。我 要知道SQLite可以优雅地将数据集处理成数百MB的大小 两位数的GBs(也许比脏页映射实现还要多)

因此,如果您有一个应用程序,它使用了许多修改 显著的性能改进。但是页面争用是一个关键问题 变量。如果您有一个BDB数据库,其数据由 在任何情况下,它的性能都将与SQLite相匹配 数据库级锁定——每个人都在为一件事争吵。然而,作为 从那时起,记忆成为下一个限制因素。但那是另一回事 故事。

顺便说一句,我正在写一篇关于使用BDB的文章

文章链接:

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

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

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

不过,这是最好的情况——根据传入的数据和当前在伯克利存储的内容,有时插入速度可能会降至每秒2千次。如果磁盘I/O速度慢,缓存命中率低,或者不断扩展数据库导致页分裂,则性能会显著下降。为了提高特定数据集的性能,还可以进行大量的调整。

The BerkeleyDB Book 可能是目前最好的参考。

除了Brian提到的Berkeley DB书之外,您还可能发现以下资源非常有用:

• Berkeley DB在线论坛可以从用户和产品开发人员那里提供很多建议。看到了吗 Berkeley DB forum ,
• Berkeley DB文档集 here