在 Berkeley DB Core 和 Berkeley DB JE 之间进行选择

Posted 2023-02-16

【中文标题】在 Berkeley DB Core 和 Berkeley DB JE 之间进行选择

【英文标题】：Choosing between Berkeley DB Core and Berkeley DB JE

【发布时间】：2010-04-07 15:13:50

【问题描述】：

我正在设计一个基于 Java 的网络应用程序，我需要一个键值对存储。 Berkeley DB 似乎很适合我，但似乎有两个 Berkeley DB 可供选择：用 C 实现的 Berkeley DB Core 和用纯 Java 实现的 Berkeley DB Java 版。

问题是，如何选择使用哪一个？对于 web-apps 的可扩展性和性能非常重要（谁知道呢，也许我的想法会成为下一个 Youtube），而我在两者之间找不到任何有意义的基准。我还没有熟悉 Cores Java API，但我很难相信它会比 Java 版本差很多，这似乎相当不错。

如果其他一些键值存储会更好，也请随意推荐。我正在存储较小的二进制 blob，键可能是数据的哈希值或其他一些唯一 ID。

【参考方案1】：

我有相当多的使用 Java 的 BDB-JE 和 BDB-core 的经验。决定使用哪一个非常简单：如果您想要并发，请使用 BDB-JE。如果您想要可扩展性，请使用 BDB-core。

由于 BDB-JE 的文件格式和依赖 Java 垃圾收集来清理被驱逐的缓存条目，因此 BDB-JE 在大型数据库的性能方面存在问题。预计长时间的垃圾收集暂停或花费大量时间调整魔法 GC 设置。文件格式也有问题，因为后台清理线程必须花费大量时间清理早期缓存驱逐产生的垃圾。如果您的数据库适合 RAM，则 BDB-JE 工作得很好。

BDB-core 依赖于页面锁定策略，高并发应用程序会遇到很多死锁。如果您可以随机排序操作，它会减少死锁的可能性，但它永远不会消除它。由于 BDB-core 以更传统的方式存储数据，因此它可以扩展到超大尺寸，并具有可预测和预期的性能下降。因为它的缓存不是由垃圾收集器管理的，所以它可以很大并且不会导致任何暂停。

【参考方案2】：

如果您派生出这些的通用接口，并且拥有一组合适的单元测试，那么您应该能够在以后轻松地在两者之间进行交换（也许当您确实需要根据以下事实做出决定时）暂时不可用）

【讨论】：

对此只是一个警告：数据库本身将不会在版本之间移植。如果您沿着这条路线走，如果您发现自己想要交换实现，您将需要数据本身的迁移策略。因此，如果数据的可移植性很重要，您最好使用 Berkeley DB 和 Java API 而不是 Java 版。

【参考方案3】：

我遇到了同样的问题并决定使用 Java 版本，主要是因为它的可移植性（我需要可以在移动设备上运行的东西）。还有 Direct Persistence Layer (DPL) API，而且整个 db 是单个 jar 的事实使其部署相当简单。

最新版本 4 带来了高可用性和性能改进。还有一个事实是，长时间运行的 java 应用程序可以实现这样的优化，在某些情况下它们会超过原生 C 应用程序的性能。

它非常适合任何 Java 应用程序 - 桌面或网络。

【参考方案4】：

我之前也有同样的问题，在做了一些基准测试后，我发现原生版本中的哈希模式比 Java 版本提供的任何东西都更快且存储效率更高，所以我决定使用原生实现.

我建议您针对您期望的存储容量进行自己的基准测试，并确定 Java 版本是否足够快。

如果是，或者如果性能对您来说不是一个大问题（这对我来说很重要），那就选择 Java 版本。否则请使用本机（假设您看到自己的用例具有相同的性能提升）。

顺便说一句： 我的基准测试是从 20,000,000 条记录中查询随机键的速度，其中键是字符串，值是 int（4 字节）。 我看到原生版本的插入（填充基准测试）要快得多，查询速度也快了一倍。

（这不是由于 Java 的缺点，而是因为 Java 版本与本机版本不同 - 4.0 与 4.8 IIRC）。

【参考方案5】：

我决定使用 Java 版，只是因为它可以将数据库运行时嵌入到同一个可部署文件中。这是我设置的一个重要功能。我没有在核心和 JE 之间进行基准测试，但与我在首次评估数据库存储时测试的其他键值存储相比，我看到了出色的性能。

如果您正在创建一个 Web 应用程序，那么从长远来看，并发性对您来说可能非常重要。