这取决于您正在构建的应用程序的类型。创建一个有代表性的测试场景，并开始着手进行。然后你就会知道确切的答案。
除了您的用例之外，它还取决于CPU、内存、前端总线、操作系统、缓存设置等。
说真的，测试一下你自己的场景。
如果你需要一些数字（实际上在你的场景中可能没有任何意义）：

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

我非常同意Daan的观点：创建一个测试程序，并确保它访问数据的方式尽可能地模仿您希望应用程序具有的模式。这对于BDB来说非常重要，因为不同的访问模式会产生非常不同的吞吐量。
除此之外，我发现以下是对吞吐量有重大影响的一般因素：
1.访问方法（在您的情况下，我猜是BTREE）。
1.配置DBD时的持久性级别（例如，在我的示例中，'DB_TXN_WRITE_NOSYNC'环境标志将写入性能提高了一个数量级，但它会影响持久性）
1.工作集是否适合缓存？
1.读取次数与写作。
1.如何分散你的访问（记住BTREE有一个页面级别的锁定-所以用不同的线程访问不同的页面是一个很大的优势）。
1.访问模式--意味着线程相互锁定甚至死锁的可能性有多大，以及死锁解决策略是什么（这可能是一个杀手）。
1.硬件（磁盘和缓存内存）。
这相当于以下一点：扩展基于DBD的解决方案以提供更大的并发性有两个关键方法：要么在设计中最小化锁的数量，要么添加更多的硬件。

这不是取决于硬件以及线程的数量和东西吗？
我会做一个简单的测试，并运行它与不断增加的线程锤击量，看看什么似乎是最好的。

在处理性能未知的数据库时，我所做的是测量查询的周转时间。我不断增加线程数，直到周转时间下降，并降低线程数，直到周转时间改善（好吧，这是我的环境中的进程，但无论如何）。
其中涉及移动平均线和各种指标，但从中得到的教训是：适应现在的情况您永远不知道DBA何时会提高性能，或者硬件何时会升级，或者在您运行时，可能会沿着另一个进程来加载系统。所以适应吧。
还有一件事：如果可以的话，避免过程切换-批量处理。
我得说清楚这一切都发生在运行时，而不是在开发期间。

据我所知，桑巴舞创建了tdb，以允许对任何特定的数据库文件进行“多个并发 * writer *”。因此，如果您的工作负载有多个编写器，您的性能可能会很差（例如，桑巴舞项目选择编写自己的系统，显然是因为它对Berkeley DB在这种情况下的性能不满意）。
另一方面，如果您的工作负载有很多读取器，那么问题是您的操作系统处理多个读取器的能力如何。