1

我正在使用 YCSB 基准测试工具对 Couchdb 和 Mongodb 的性能进行基准测试。不幸的是，我似乎做错了，因为单个随机操作的性能差异很大：

工作负载 A（50/50 读取/更新），16 个查询线程，120 秒运行时间（结果与 20 分钟运行时间非常相似）：

CouchDB 1.6.1：整体吞吐量：1076 ops/sec，99th percentile 读取延迟 13ms，99th percentile 更新延迟 13ms

MongoDB 3.0.6：总吞吐量：11203 ops/sec，99th percentile 读取延迟 1ms，99th percentile 更新延迟 1ms

如您所见，CouchDB 对于随机读取和更新非常慢。文档建议使用可能对插入很好的批量操作，但考虑到 YCSB 正在逐一请求读取，我看不出我将如何实现批量读取。

测试环境：

  • Ubuntu 14.04 64bit 在 i7 主机上的虚拟机上启用了 VT-D，2 核，2gb ram（尽管我在专用机器上得到了类似的结果）
  • 工作集/db 很容易放入 ram
  • 本地主机服务器，无硬件网络延迟（硬件集群上的结果相似）
  • CouchDB 文档中提到的所有应该提高性能的东西，尤其是 HTTPD 选项和 simplejson 的 C 扩展都设置正确
  • 我使用 CouchDB 网站上推荐的 Ektorp 持久性 API 编写了 couchdb 驱动程序。代码很简单，我为其他数据库系统编写的驱动程序运行良好。

我试图提高吞吐量的方法：

  • 在加载阶段使用批量插入。这使得 CouchDB 快很多，但仍然比 MongoDB 慢 7 倍，这与此处发布的基准一致，使用相同的 CouchDB 版本。

CouchDB 运行缓慢的可能解释：

  • 必须通过请求文档、修改文档并将其重新提交到数据库来完成更新，这会导致高延迟。然而，这并不能解释低读取吞吐量

问题：您是否看到任何其他提高 CouchDB 性能的方法？

编辑：Delayed_commit 在 couchdb 中设置为 true，所以我开始怀疑强制 fsync 是原因。

4

1 回答 1

1

这里的答案很简单：CouchDB 使用 fsync() 调用确保所有写入都命中磁盘，而 MongoDB 允许将它们保留在内存中一段时间​​并告诉您一切都很好。直到您丢失数据时下一次意外关机。RAM-vs-disk 是它们之间的主要性能因素。

接下来是协议：HTTP 是文本，而 MongoDB 使用自己的二进制文件。不用说，二进制协议更加紧凑和高效。

但这里的主要问题是您的基准是综合的。你假设你的数据库被用于愚蠢的读写，比如数据包，而数据库被用于更复杂的操作，比如查询、索引查找、连接、数据验证等。在这里，业务逻辑很重要。

对于更真实的基准测试，您应该使用一些应用程序并使其与数据库和基准业务工作流程一起使用，而不是盲目读/写。可以肯定的是，您的数字将相等，因为业务逻辑比任何数据库都慢得多。

所以我很抱歉你在这件事上浪费了时间。

于 2015-09-06T12:30:42.550 回答