上限收集性能问题 [英] Capped Collection Performance Issues

问题描述

我正在做一些测试，看看我可以从 Mongodb 获得什么样的吞吐量.文档说上限集合是最快的选择.但是我经常发现我可以更快地写入普通集合.根据具体的测试，我通常可以通过正常收集获得两倍的吞吐量.

I'm doing some tests to see what kind of throughput I can get from Mongodb. The documentation says that capped collections are the fastest option. But I often find that I can write to a normal collection much faster. Depending on the exact test, I can often get twice the throughput with a normal collection.

我错过了什么吗?我该如何解决这个问题?

Am I missing something? How do I troubleshoot this?

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

I have a very simple C++ program that writes about 64,000 documents to a collection as fast as possible. I record the total time, and the time that I'm waiting for the database. If I change nothing but the collection name, I can see a clear difference between the capped and normal collections.

> 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

linux version: 3.4.11-1.fc16.x86_64

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

mongo version: db version v2.2.2, pdfile version 4.5

这是一台只运行 Mongodb 服务器和我的测试客户端的专用机器.在这次测试中，这台机器的性能太强大了.

This is a dedicated machine doing nothing but running the Mongodb server and my test client. The machine is ridiculously overpowered for this test.

推荐答案

我看到了这个问题.我上面引用的网页说，没有索引"的上限集合将提供高性能.但是……

I see the problem. The web page I quoted above says that a capped collection "without an index" will offer high performance. But…

http://docs.mongodb.org/manual/core/indexes/ 说在 2.2 版之前，封顶集合没有 _id 字段.在 2.2 中，所有封顶集合都有一个 _id 字段，本地数据库中的除外."

http://docs.mongodb.org/manual/core/indexes/ says "Before version 2.2 capped collections did not have an _id field. In 2.2, all capped collections have an _id field, except those in the local database."

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

I created another version of my test which writes to a capped collection in the local database. Sure enough, this collection did not have any indexes, and my throughput was much higher!

也许 http://docs.mongodb.org/上的上限集合概述手册/核心/上限集合/ 应该澄清这一点.

Perhaps the overview of capped collections at http://docs.mongodb.org/manual/core/capped-collections/ should clarify this point.

这篇关于上限收集性能问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！