MongoDB vs CouchDB（速度优化）答案

【问题标题】：MongoDB vs CouchDB (Speed optimization)MongoDB vs CouchDB（速度优化）
【发布时间】：2011-02-26 15:38:09
【问题描述】：

我做了一些速度测试来比较 MongoDB 和 CouchDB。测试时只有插入。我得到的 MongoDB 比 CouchDB 快 15 倍。我知道这是因为套接字与 http。但是，我很感兴趣如何优化 CouchDB 中的插入？

测试平台：Windows XP SP3 32 位。我使用了 MongoDB 的最新版本、MongoDB C# 驱动程序和 CouchDB for Windows 的最新版本 installation package。

谢谢！

【问题讨论】：

标签： windows performance testing mongodb couchdb

【解决方案1】：

我不认为套接字和http之间的区别是唯一的区别。差异也与磁盘同步（fsync）有关。这会影响耐用性。 MongoDB 首先将所有内容存储在 RAM 中，并且它只会以特定的时间间隔同步到磁盘，除非您明确告诉 MongoDB 进行 fsync。

了解持久性和 MongoDB：http://blog.mongodb.org/post/381927266/what-about-durability 和 fsync：http://www.mongodb.org/display/DOCS/fsync+Command

【讨论】：

我忘记了数据刷新；）谢谢！

【解决方案2】：

为了以批量方式将大量数据插入数据库，CouchDB 支持 批量插入，在 wiki 中的HTTP Bulk Document API 下进行了描述。

此外，请查看上面链接中描述的 delayed_commits 配置选项和 batch=ok 选项。这些选项可以通过定期与磁盘同步来实现类似的内存缓存行为。

【讨论】：

你说得对！它很有帮助；）我尝试在 1000 x 1000 块内存储 1M 数据结构。速度非常快！谢谢你们。现在我有了解决方案；）
不客气！接下来我将添加另一个更具争议性的答案。
当然，MongoDB 也支持批量插入......这再次使它比 Couch 快 15 倍。

【解决方案3】：

这是我一直在考虑但尚未进行基准测试的想法。我希望它在某些情况下会很棒：

插入吞吐量必须很高
不需要按键获取单个文档
所有数据都是通过视图获取的（可能与接收插入的机器不同）

计划

插入成批的文档，并使用视图将它们很好地序列化。

示例

考虑一个带有简单时间戳和消息字符串的日志文件。

0.001 Start
0.123 This could be any message
0.500 Half a second later!
1.000 One second has gone by
2.000 Two seconds has gone by
[...]
1000.000 One thousand seconds has gone by

您可以在每个文档中插入一条消息，例如：

{ "_id": "f30d09ef6a9e405994f13a38a44ee4a1",
  "_rev": "1-764efa883dda1e11db47671c4a3bbd9e",
  "timestamp": 0.123,
  "message": "This could be any message"
}

标准批量文档优化

第一个优化是使用_bulk_docs 插入，如the CouchDB bulk-docs documentation。

二次批量插入优化

但是，第二优化是将日志预批处理到一个更大的 Couch 文档中。例如，4 个批次（在现实世界中这会更高）：

{ "_id": "f30d09ef6a9e405994f13a38a44ee4a1",
  "_rev": "1-764efa883dda1e11db47671c4a3bbd9e",
  "logs": [
    {"timestamp": 0.001, "message": "Start"},
    {"timestamp": 0.123, "message": "This could be any message"},
    {"timestamp": 0.500, "message": "Half a second later!"},
    {"timestamp": 1.000, "message": "One second has gone by"}
  ]
}

{ "_id": "74f615379d98d3c3d4b3f3d4ddce82f8",
  "_rev": "1-ea4f43014d555add711ea006efe782da",
  "logs": [
    {"timestamp": 2.000, "message": "Two seconds has gone by"},
    {"timestamp": 3.000, "message": "Three seconds has gone by"},
    {"timestamp": 4.000, "message": "Four seconds has gone by"},
    {"timestamp": 5.000, "message": "Five seconds has gone by"},
  ]
}

当然，您也可以通过_bulk_docs 插入这些数据，有效地插入成批的数据。

查看还是很容易的

将日志序列化回视图仍然很容易：

// map
function(doc) {
  if(doc.logs) {
    // Just unroll the log batches!
    for (var i in doc.logs) {
      var log = doc.logs[i];
      emit(log.timestamp, log.message);
    }
  }
}

然后很容易获取时间戳在startkey、endkey 之间的日志，或者您有任何其他需求。

结论

这仍然没有进行基准测试，但我希望，对于某些类型的数据，批处理成块将减少内部 B-tree 写入。结合_bulk_docs，我希望看到插入吞吐量达到磁盘的硬件速度。

【讨论】：

有趣，我想知道你能用 Erlang 写那个视图定义吗？我听说 Erlang 更快。
我实际上在一年前在 Mozilla 为测试结果做了类似的事情。您肯定是视图生成的瓶颈。当时，较旧的蜘蛛猴对于大型文档来说是一个巨大的瓶颈，所以我编写了一个新的 Python 视图服务器。 mikealrogers.com/archives/673 我打赌用更新的蜘蛛猴 JSON 序列化问题会消失，这值得再次进行基准测试。但请记住，视图结果仍然是磁盘上的 btree，并且视图在 fsync 完成之前不可用，因此它无法与 Redis 或 MongoDB 进行比较。
Mikeal，是的，我认为它只会在非常特殊的情况下才会发光。例如，日志被转储到一个数据库中，该数据库复制到，我不知道，也许是一个休息室，它可以浏览您需要的所有视图行。一方面，以磁盘速度插入会很酷；但这将是最终的“基准”（贬义使用）
CouchDB 不是最适合记录的数据库。高可靠性、快速（ish）读取、预煮查询和慢速写入；它基本上与一个好的记录器数据库相反（可靠性无关紧要，读取无关紧要，即席查询和快速写入 - 也许是 Cassandra？）。

【解决方案4】：

只是迭代套接字与 HTTP 和 fsync 与内存中的对话。

默认情况下，MongoDB 不会在写入调用时返回响应。您只需将数据写入套接字并假设它在数据库中并且可用。在并发负载下，这可能会被备份，并且没有一个好方法可以知道 Mongo 真正有多快，除非您使用一个可选调用，该调用将在数据可用时返回写入响应。

我并不是说 Mongo 插入性能不比 Couch 快，插入内存比 fsyncing 磁盘快得多，这里更大的区别在于 MongoDB 和 CouchDB 在一致性和持久性方面的目标不同。但是我见过的所有用于测试 Mongo 的“性能”工具都使用默认的写入 API，因此您并没有真正测试插入性能，而是在测试刷新到套接字的速度。

我看到很多基准测试表明 Mongo 比 Redis 和 memcached 更快，因为他们没有意识到当数据在内存中时 Redis 和 Memcached 返回响应而 Mongo 没有。 Mongo 绝对不比 Redis 快 :)

【讨论】：