Aggregation FWの特徴と地雷

MongoDBのAggregation FWはSQLの集約関数(COUNT,SUM,GROUP等)の様な組み込み機能の集合である。

非常に便利なのだが、色々と問題があって、手放しにはお勧めできない。

Aggregation FWの機能や利用する時のハマリ所をリストアップしてみた。

機能

MapReduceの様にロジックを投入できる訳ではなく、組み込みの機能を利用するだけなので、柔軟性は無いものの殆どの用途に十分なほどの機能が用意されている。

1. noscripting=trueで運用できる

なによりサーバサイドでスクリプトを走らせるリスクを回避できる事が最大のポイント

2. SECONDARYで動作

Primaryへの負荷を掛けることなく動作できる。
専用のhiddenノードで運用すすればオンライン系への負担も無いのでとても便利。

3. パイプライン

多段の集計が可能。ある意味SQLより強力。（サブクエリーでも一応できるが、、）
$match (WHERE) -> $group (GROUP BY) -> $match (HAVING) -> $group -> $sort

4. SQLのGROUP BYより高度な集計

配列が扱える

GROUP BYを掛けつつ、ある要素はユニーク要素が配列で欲しい。など

FIRST/LAST

GROUP BYで集計毎に最初の要素が欲しい。など。。

5. 主な機能

こちら

地雷リスト

1.　メモリー制限

クエリーが10%以上のメモリーを使うと強制的に殺されるようだ。

（多分MongoDB全体の制限）

terminating request:  request heap use exceeded 10% of physical RAM

これでは満足な集計が出来ない。
ソート系は特にヤバイ。

上記の様に折角hidden secondaryで動作できる仕様の割に中途半端な制限。

2.　Sharding環境では、、

mongosにクエリーを投げる事で、各Shardへのリクエストはヨロシクやってくれるのだが
なんとPRIMARYノードに投げてしまう！
この制御方法もなさそうだ。。
これでは使えない・・・

結果的に大規模なデータでは使えないということ。

3.　16MB制限

全集計結果が16MBに収まらなければならない。
やはり巨大なデータセットの解析には無力。

これじゃ受け取る側もツライし、カーソルで返してくれるのが普通だと思うのだが・・・

結論

そんな訳で、、
AggregationFWは便利なのだが、現状では中途半端な感が否めない。
まだお勧めできる状態にあるとは言えないな。

これらを解ってて使う分には良いが
AggregationFWに頼ったシステムを構築すると、後々痛い目を見るだろう。

やはり解析はMongoDBの外で行った方が良いと思う。
MongoHadoopか、、
チャレンジングな人はMonmoちゃん使ってあげて！！w