封顶收集性能问题

Question

我正在做一些测试，看看我可以从Mongodb获得什么样的吞吐量。文档中说有上限的集合是最快的选择。但是我经常发现我可以更快地写到一个普通的集合。根据准确的测试，我通常可以使用普通集合获得两倍的吞吐量。

我是不是遗漏了什么？如何对此进行故障排除？

我有一个非常简单的C++程序，可以尽可能快地将大约64,000个文档写入到一个集合中。我记录总时间，以及我等待数据库的时间。如果我只更改了集合名称，我可以看到capped和normal集合之间的明显区别。

> use tutorial
switched to db tutorial
> db.system.namespaces.find()
{ "name" : "tutorial.system.indexes" }
{ "name" : "tutorial.persons.$_id_" }
{ "name" : "tutorial.persons" }
{ "name" : "tutorial.persons.$age_1" }
{ "name" : "tutorial.alerts.$_id_" }
{ "name" : "tutorial.alerts" }
{ "name" : "tutorial.capped.$_id_" }
{ "name" : "tutorial.capped", "options" : { "create" : "capped", "capped" : true, "size" : 100000000 } }
> db.alerts.stats()
{
    "ns" : "tutorial.alerts",
    "count" : 400000,
    "size" : 561088000,
    "avgObjSize" : 1402.72,
    "storageSize" : 629612544,
    "numExtents" : 16,
    "nindexes" : 1,
    "lastExtentSize" : 168730624,
    "paddingFactor" : 1,
    "systemFlags" : 1,
    "userFlags" : 0,
    "totalIndexSize" : 12991664,
    "indexSizes" : {
        "_id_" : 12991664
    },
    "ok" : 1
}
> db.capped.stats()
{
    "ns" : "tutorial.capped",
    "count" : 62815,
    "size" : 98996440,
    "avgObjSize" : 1576,
    "storageSize" : 100003840,
    "numExtents" : 1,
    "nindexes" : 1,
    "lastExtentSize" : 100003840,
    "paddingFactor" : 1,
    "systemFlags" : 1,
    "userFlags" : 0,
    "totalIndexSize" : 2044000,
    "indexSizes" : {
        "_id_" : 2044000
    },
    "capped" : true,
    "max" : 2147483647,
    "ok" : 1
}

linux版本: 3.4.11-1.fc16.x86_64

mongo版本: db版本v2.2.2，pdfile版本4.5

这是一台专门的机器，除了运行Mongodb服务器和我的测试客户机之外，什么也不做。这台机器在这次测试中超强得离谱。

Answer 1

我看到了问题所在。我在上面引用的网页上说，一个“没有索引”的有上限的集合将提供高性能。但是…

http://docs.mongodb.org/manual/core/indexes/说：“在2.2版本之前，上限集合没有_id字段。在2.2版本中，除了本地数据库中的集合之外，所有上限集合都有_id字段。”

我创建了我的测试的另一个版本，它写入本地数据库中的上限集合。果然，这个集合没有任何索引，并且我的吞吐量要高得多！

也许http://docs.mongodb.org/manual/core/capped-collections/上的上限集合概述应该澄清这一点。

Answer 2

Capped集合保证了插入顺序的保留。因此，查询不需要索引就可以按插入顺序返回文档。如果没有这种索引开销，它们可以支持更高的插入吞吐量。

根据上面的定义，如果您没有任何索引插入到上限集合中，则不必比插入到普通集合中更快。所以如果你没有任何索引，如果你没有任何其他的理由去使用有上限的集合，比如缓存，显示最后n个元素之类的东西，我建议你使用常规的集合。

上限集合保证插入顺序与磁盘上的顺序相同(自然顺序)，并通过禁止增加文档大小的更新来做到这一点。设置了上限的集合仅允许适合原始文档大小的更新，这确保了文档不会更改其在磁盘上的位置。