45

Oracle 最近发布了 SQLite 的 Berkeley DB 后端。我碰巧有一个数百兆字节的 SQLite 数据库,它可以很好地受益于“改进的性能、并发性、可伸缩性和可靠性”,但 Oracle 的网站似乎缺乏任何改进的衡量标准。这里有人做过基准测试吗?

4

3 回答 3

58

我参与了 BDB SQLite 代码的 beta 评估,我试图处理的一件事是性能差异。在这一点上,我无法准确发布我发现的内容,直到我至少有另一个人评估我的代码、运行测试并确认我得到的数字(正在完成)。但是,我可以概括地说,在某些情况下,BDB 比 SQLite 提供了显着的性能改进,特别是在处理涉及写入并发的重负载方面。

通常,有两种“快速”正确的衡量标准——(1)效率:单个进程执行 XYZ 与(2)并发性:单位时间内多个进程可以执行多少次 XYZ。BDB 解决的主要问题是并发——大规模事务处理。因此,您会想到许多并发连接写入和/或修改数据库的内容。

SQLite 在设计上使用数据库级锁定,因此一次最多可以有一个写入者在数据库中工作。因此,SQLite 的事务率或多或少与并发连接数保持一致,因此它在写入密集型应用程序中的可扩展性实际上是通过其效率来衡量的 (1)。

另一方面,BDB 使用页级锁定,它允许多个写入者在给定时间在数据库中工作(前提是他们在单独的页面上工作)。因此,BDB 的速率可能会随着连接数量的增加而增加,因此它的可扩展性既是效率问题(1)又是并发问题(2),两者可以叠加。

主要归结为(写)并发。BDB 可以为多个写入者推送比 SQLite 更多的 TPS。通过事务,我的意思是修改数据库的东西(它们对只读操作有什么真正的帮助?)。也就是说,对于读取并发(主要执行 SELECT 的应用程序),SQLite 可以很好地与 BDB 正面交锋,因为锁定不再是一个关键问题。

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

因此,如果您的应用程序使用许多修改给定数据库的连接并且页面争用相对较低,那么 BDB 可以提供显着的性能改进。但是页面争用是一个关键变量。在极限情况下,如果您有一个 BDB 数据库,其数据由单个页面组成,那么它的性能在所有情况下都将与 SQLite 相媲美,因为这里的页面级锁定有效地退化为等效于数据库级锁定——每个人都在争夺一件事。但是,随着 BDB 中页面数量的增加(以及页面争用的减少),最大 TPS 将随着并发连接数的增加而开始增长。然后从那时起,内存成为下一个限制因素。但那是另一回事了。

顺便说一句,我正在为那些来自 SQLite 的人写一篇关于使用 BDB 的文章。

文章链接:

Oracle Berkeley DB SQL API 与 SQLite API – 技术评估

Oracle Berkeley DB SQL API 与 SQLite API – 集成、优势和差异

于 2010-05-18T20:29:51.943 回答
11

这是一个有点负荷的问题。结果会因您的磁盘访问速度、内存中缓存的大小、插入与读取的数量、页面拆分、并发性等等因素而有很大差异。

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

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

总体而言,这是一个出色的系统,但文档和知识相当少。我推荐The BerkeleyDB Book作为目前最好的参考书。

于 2010-05-17T22:57:49.467 回答
7

除了 Brian 提到的 Berkeley DB Book,您可能还会发现以下资源很有用:

  • Berkeley DB 在线论坛可以提供来自用户和产品开发人员的大量建议。请参阅Berkeley DB 论坛
  • Berkeley DB 文档集,可在此处找到。特别是,参考指南中有几个部分涵盖了调优、性能和吞吐量。
于 2010-05-18T20:56:38.833 回答