BerkeleyDB 并发

Question

• BerkeleyDB 的 C++ 实现可以合理支持的最佳并发级别是多少？
• 在吞吐量开始因资源争用而受到影响之前，我可以有多少线程在数据库上敲打？

我已经阅读了手册并知道如何设置锁的数量、储物柜、数据库页面大小等。但我只想从拥有 BDB 并发实际经验的人那里得到一些建议。

我的应用程序非常简单，我将执行获取和放入每个大约 1KB 的记录。 没有游标，没有删除。

Answer 1

这取决于您正在构建的应用程序类型。 创建一个有代表性的测试场景，然后开始锤炼。 然后你就会知道最终的答案。

除了您的用例，它还取决于 CPU、内存、前端总线、操作系统、缓存设置等。

说真的，只是测试你自己的场景。

如果您需要一些数字（这在您的场景中实际上可能没有任何意义）：

• Oracle Berkeley DB：性能指标和基准
• 性能指标和基准：
  伯克利数据库

Answer 2

我非常同意 Daan 的观点：创建一个测试程序，并确保它访问数据的方式尽可能地模仿您希望应用程序具有的模式。 这对于 BDB 非常重要，因为不同的访问模式会产生非常不同的吞吐量。

除此之外，我发现这些是对吞吐量有重大影响的一般因素：

1. 访问方法（在你的情况下我猜是 BTREE）。

2. 您配置 DBD 的持久性级别（例如，在我的例子中，'DB_TXN_WRITE_NOSYNC' 环境标志将写入性能提高了一个数量级，但它损害了持久性）

3. 工作集是否适合缓存？

4. 读取次数 Vs。 写。

5. 您的访问的分散程度（请记住，BTREE 具有页面级锁定 - 因此使用不同的线程访问不同的页面是一个很大的优势）。

6. 访问模式 - 意味着线程相互锁定甚至死锁的可能性有多大，以及您的死锁解决策略是什么（这可能是一个杀手）。

7. 硬件（用于缓存的磁盘和内存）。

这相当于以下几点： 扩展基于 DBD 的解决方案以提供更高的并发性有两个关键的方法： 要么最大限度地减少设计中的锁数量，要么添加更多硬件。

Answer 3

这不取决于硬件以及线程和东西的数量吗？

我会做一个简单的测试，并用越来越多的线程锤击来运行它，看看什么是最好的。

Answer 4

在处理性能未知的数据库时，我所做的是测量查询的周转时间。 我一直增加线程数直到周转时间下降，并减少线程数直到周转时间得到改善（嗯，这是我环境中的进程，但无论如何）。

有移动平均线和各种指标，但外卖的教训是：只是适应目前的工作方式。 您永远不知道 DBA 何时会提高性能或硬件何时会升级，或者在您运行时可能会出现另一个进程来降低系统负载。 所以适应。

哦，还有一件事：如果可以，请避免流程切换 - 批量处理。

---

哦，我应该说清楚：这一切都发生在运行时，而不是在开发过程中。

Answer 5

根据我的理解，Samba 创建了tdb以允许任何特定数据库文件的“多个并发编写者”。 因此，如果您的工作负载有多个编写器，您的性能可能会很差（例如，Samba 项目选择编写自己的系统，显然是因为它对 Berkeley DB 在这种情况下的性能不满意）。

另一方面，如果您的工作负载有很多读者，那么问题是您的操作系统处理多个读者的能力如何。