Oracle最近发布了a Berkeley DB back-end to SQLite。我碰巧有一个数百兆字节的SQLite数据库,它可以从“改进的性能,并发性,可伸缩性和可靠性”中获益,但Oracle的网站似乎缺乏任何测量的改进。有没有人在这里做过一些基准测试?
答案 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之外,您还可以找到以下资源: