推荐使用CappedCollection

在Gunosy，我们在日志分析和推荐引擎方面使用了MongoDB。
不久前，在一次研讨会上，我们谈到了使用MongoDB的MapReduce进行日志分析的情况。

• MongoDBのMapReduceって遅くない？

データ量増えるとリソース相当使わない？

とのツッコミを頂きました。
指摘自体は正しいと思っていて、データ増えるとすぐ計算時間やサーバのリソース使用量が大変なことになります。

为了避免这种情况，并实现节约运用，Gunosy 在其日志分析领域使用了Capped Collection。

Capped Collection是什么？

ご存知の方も多いと思いますが、念のため本家から引用すると、

Capped collections are fixed-size collections that support high-throughput operations that insert, retrieve, and delete documents based on insertion order.

要はサイズ固定で高速に使えるcollectionだと思っていただければ結構です。

优点/长处

• サイズ固定なので不用意にリソースを使用し過ぎることがない

割と高速

缺点

後からcapサイズが変更しづらい。（できなくもないです）

如果使用Capped Collection，您可以通过以下命令进行确认。

// 新しくコレクションを作る場合
db.createCollection( "mycol", { capped: true, size: 100000 } )

// すでにコレクションが存在する場合
db.runCommand({"convertToCapped": "mycoll", size: 100000});

通过查看集合的统计数据，可以确认是否已达到上限。

> db.mycol.stats()
{
    "ns" : "test.mycol",
    "count" : 0,
    "size" : 0,
    "storageSize" : 12288,
    "numExtents" : 1,
    "nindexes" : 1,
    "lastExtentSize" : 12288,
    "paddingFactor" : 1,
    "systemFlags" : 1,
    "userFlags" : 0,
    "totalIndexSize" : 8176,
    "indexSizes" : {
        "_id_" : 8176
    },
    "capped" : true,
    "max" : NumberLong("9223372036854775807"),
    "ok" : 1
}

你是怎么使用的？

在日志分析部分，我们需要注意以下两点。

• 解析項目に合わせてログフォーマットを毎度用意している

計測に必要なログの保存日数に合わせてCapサイズを決定している。

在解析中，几乎不使用原始访问日志。
由于日志解析和服务器代码由同一人负责，因此我们根据解析项适时实现了仅发送必要的最小数据的记录器，并同时准备了用于日志汇总的脚本（使用Fluentd）。

由于访问日志中不可避免地包含路径和请求参数等内容，所以集合的大小会变得很大。但是，如果只将与分析项目真正必要的数据保存到MongoDB中，那么它不会占用太多的容量。

顺便提一下，原始的访问日志也会暂时保存在MongoDB中，但大部分会先保存到S3，然后流向Redshift。

从目前来看，这种运作方式使得分析本身并不需要太大的资源，但仍能维持下去。

这种运营方式的缺点

当需要对长期数据进行后期分析时，由于Collection内无法保存如此长期的数据，因此我们在内部使用RedShift进行存储。

总结

使用Capped Collection，即使在相对较大的规模下，也能在维持MongoDB性能的同时节约资源。