BerkeleyDB并发

Question

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

我已阅读本手册并知道如何设置锁，锁柜，数据库页面大小等数量，但我只是喜欢有BDB并发实际经验的人的一些建议。

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

Answer 1

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

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

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

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

• Oracle Berkeley DB: Performance Metrics and Benchmarks
• Performance Metrics & Benchmarks:
  Berkeley DB

Answer 2

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

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

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

2. 您配置DBD的持久性级别（例如，在我的情况下，'DB_TXN_WRITE_NOSYNC'环境标志将写入性能提高了一个数量级，但它会影响持久性）

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

4. 读取次数。写入。

5. 如何扩展您的访问权限（请记住BTREE具有页面级锁定 - 因此访问具有不同线程的不同页面是一个很大的优势）。

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

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

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

Answer 3

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

我会做一个简单的测试，然后用越来越多的线程锤击它，看看最好的东西。

Answer 4

在对未知性能数据库进行操作时，我所做的是测量查询的周转时间。我一直在增加线程数，直到周转时间减少，然后丢弃线程计数直到周转时间改善（好吧，这是我环境中的进程，但无论如何）。

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

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

---

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

Answer 5

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

另一方面，如果您的工作量有很多读者，那么问题是您的操作系统处理多个读者的程度。