Oracle 最近发布了 a Berkeley DB back-end to SQLite .我碰巧有一个数百兆字节的 SQLite 数据库，它可以很好地受益于“改进的性能、并发性、可扩展性和可靠性”，但 Oracle 的站点似乎缺乏任何改进的测量值。这里有人做过基准测试吗？
最佳答案
我参与了 BDB SQLite 代码的 beta 评估，并且是其中之一 我试图解决的问题是性能差异。在此刻， 在我至少有一个其他人之前，我无法准确发布我发现的内容 评估我的代码，运行测试，并确认我得到的数字(正在 完毕)。但是，我可以在这里概括地说，有些情况下 BDB 提供比 SQLite 显着的性能改进，特别是在 处理涉及写入并发的重负载的领域。
“快”权一般有两个衡量标准——(1)效率:多长时间 单个进程是否需要执行 XYZ 与 (2) 并发:多少次 许多进程每单位时间可以做 XYZ 吗？ BDB解决的主要问题是 并发——大规模事务处理。于是你想到了很多 并发连接写入和/或修改数据库的内容。
SQLite 在设计上使用数据库级锁定，因此最多有一个 一次可以在数据库中工作的作家。因此，SQLite 的事务 rate 或多或少与并发连接数保持不变，因此 它在写密集型应用程序中的可扩展性实际上是通过它来衡量的 效率 (1).
另一方面，BDB 使用页级锁定，允许多个写入者 在给定时间在数据库中工作(前提是他们正在 单独的页面)。因此，BDB 的速率可能会随着 连接，因此它的可扩展性既是效率问题 (1) 又是 并发(2)，可以加起来。
主要归结为(写)并发。 BDB 可以插入比 用于多个编写器的 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
关于sqlite - Berkeley DB SQL 与 SQLite 相比有多快？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2824135/