BerkeleyDB并发

Question

• 在C++实现的BerkeleyDB中，最优并发级别是多少？
• 在资源争用的情况下，我可以有多少个线程同时访问数据库而不影响吞吐量？

我已经阅读了手册，并知道如何设置锁、锁定器、数据库页面大小等，但我想听听有实际BDB并发经验的人的建议。

我的应用程序非常简单，我将对每个约1KB的记录进行获取和放置。没有游标，也没有删除操作。

- Ted Dziuba

---

@digito_evo，“hammering”不是打错了。这是正确的，而“hammered”则不是。线程不是你要敲打的东西；线程是在不断地向数据库发送请求并用它们来敲打、猛击数据库的东西。这是现在时态，不是过去时态。此外，这个问题不是关于如何进行基准测试，所以[benchmarking]标签并不适用。最佳答案建议对您的使用情况进行基准测试，但这有点不同。在我看来，许多与性能相关的问题实际上不应该被标记为[benchmarking]。 - Peter Cordes

@PeterCordes 谢谢您的纠正。我一直在修复这里一些最古老的问题中的错别字和语法错误。偶尔会犯错误。 - digito_evo

Answer 1

这取决于您正在构建的应用程序类型。创建一个具有代表性的测试场景，并开始进行测试。然后你就会得到确切的答案。

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

说真的，只需测试您自己的场景即可。

如果您需要一些数字（实际上在您的场景中可能毫无意义）：

• Oracle Berkeley DB: 性能指标和基准测试
• 性能指标和基准测试：
  Berkeley DB

- Daan

---

后一篇论文还明确表示，并未测试并发的影响。 - nponeccop

Answer 2

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

除此之外，我发现以下是对吞吐量影响最大的一般因素：

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

2. 你配置DBD时的持久性水平（例如，在我的情况下，“DB_TXN_WRITE_NOSYNC”环境标志将写入性能提高了一个数量级，但它会损害持久性）

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

4. 读取次数与写入次数的数量。

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

6. 访问模式-意味着线程彼此锁定的可能性有多大，甚至会死锁，以及你的死锁解决策略是什么（这可能是致命的）。

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

这归结为以下几点： 基于DBD的解决方案进行扩展，以提供更大的并发性有两种关键方法；要么在设计中尽量减少锁的数量，要么增加更多的硬件。

- yoav.aviram

Answer 3

这不仅取决于硬件，还取决于线程数量等因素吗？

我建议进行简单的测试，并逐步增加线程数进行压力测试，以确定最佳方案。

- svrist

Answer 4

当我在处理未知性能的数据库时，我会测量查询的周转时间。我不断增加线程数，直到周转时间降低，然后减少线程数，直到周转时间改善（在我的环境中是进程，但无论如何）。其中涉及了移动平均和各种指标，但带走的教训是：要适应当前的工作情况。你永远不知道DBA何时会提高性能或硬件将会升级，或者可能会有另一个进程在运行时加载系统。所以要适应。

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

哦，我应该澄清一下：所有这些都发生在运行时，而不是开发过程中。

- Josh

Answer 5

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

另一方面，如果您的工作负载有大量读取器，则问题在于您的操作系统如何处理多个读取器。

- Max Lybbert