Berkeley DB SQL与SQLite相比有多快？
Oracle最近向SQLite发布了一个Berkeley DB后端 。 我碰巧有一个数百兆字节的SQLite数据库，可以很好地从“改进的性能，并发性，可伸缩性和可靠性”中受益，但是甲骨文的网站似乎缺乏对这些改进的测量 。 有没有人在这里做过一些基准testing？
我参与了BDB SQLite代码的testing评估，我尝试去处理的一个问题是性能上的差异。 在这一点上，我不能准确地发布我发现的东西，除非我至less有一个其他人评估我的代码，运行testing，并确认我得到的数字（正在完成）。 不过，我可以在这里概括一下，并说有些情况下BDB提供了比SQLite显着的性能改进，特别是在处理涉及写入并发的重负载方面。
一般来说，有两个“快速”正确的措施 – （1）效率：单个进程需要多长时间才能完成XYZ和（2）并发：每个单位时间多less个进程可以执行XYZ。 BDB地址的主要问题是并发性 – 大规模事务处理。 因此，您会想到写入和/或修改数据库内容的许多并发连接。
按照devise，SQLite使用数据库级locking，因此一次最多只能有一名作者在数据库中工作。 因此，SQLite的事务率与并发连接数保持不变，所以它在写密集型应用程序中的可伸缩性实际上是由其效率（1）来衡量的。
另一方面，BDB使用页面级locking，允许多个作者在给定的时间在数据库中工作（假设他们在单独的页面上工作）。 因此，BDB的速率可能会随着连接数量的增加而增加，所以它的可扩展性既是效率（1）又是并发（2）的问题，可以加起来。
主要归结为（写）并发性。 BDB可以为多个作者推送比SQLite更多的TPS。 通过交易，我的意思是修改数据库的东西（它们对于只读操作有什么真正的帮助？）。 也就是说，为了读取并发性（主要用于SELECT的应用程序），SQLite可以很好地与BDB交涉，因为locking不再是关键问题。
至于数据集的大小，我不确定。 我没有看到这一点。 最终，他们都使用B型树来存储。 在他们各自的实现中可能会考虑一些因素，但我没有调查过。 我知道SQLite可以优雅地将数据集处理成数百MB和两位数GB（现在可能更多的脏页映射实现已经被改变）。
因此，如果您的应用程序使用了许多连接来修改给定的数据库，并且页面争用相对较less，那么BDB可以提供显着的性能改进。 但页面争用是一个关键variables。 在极限情况下，如果你有一个BDB数据库，其数据由一个页面组成，那么它的性能将与所有情况下的SQLite性能相匹配，因为页面级locking有效地退化为数据库级locking – 每个人都在争夺一件事。 但是，随着BDB页数增加（页面争用减less），最大TPS将随并发连接数的增加而开始增长。 那么从那时起，记忆成为下一个限制因素。 但这是另一回事。
顺便说一句，我正在写关于使用BDB来自SQLite的文章的过程。
文章链接：
Oracle Berkeley DB SQL API与SQLite API – 技术评估
Oracle Berkeley DB SQL API与SQLite API – 集成，优点和差异
这是一个有问题的问题。 结果将根据您的磁盘访问速度，内存中的caching大小，插入次数与读取次数，页面拆分，并发性等等而有很大的不同。
总的来说，BerkeleyDB 可以非常快 – 我最近为一个雇主devise了一个数据分析平台，它能够在一个8核x86系统上每秒处理4万个插入（同时每秒处理数千次）数据集在30G范围内。 这是完全交易保护。
这是最好的情况 – 有时插入可能降到2k每秒，这取决于传入的数据和当前存储在伯克利的内容。 如果您的磁盘I / O速度较慢，caching命中率较低，或者不断扩展数据库，导致页面拆分发生，则性能会显着下降。 还可以进行大量的调整来提高特定数据集的性能。
总的来说，这是一个很好的系统，但是文档和知识是相当渺茫的。 我build议BerkeleyDB Book可能是目前可用的最好的参考。
除了Brian提到的伯克利数据库书以外，您还可以find以下资源：
- Berkeley DB在线论坛可以为用户和产品开发者提供许多build议。 看到Berkeley DB论坛 ，
- 伯克利DB文档集，可以在这里find。 “参考指南”中有几个部分特别介绍了调谐，性能和吞吐量。
