運用での capped コレクションサイズ設定

[Nishimura Ryuichiro]

いつもお世話になっております。

掲題の件で参考意見等伺いたく投稿させていただきます。

現在、システムでMongoDB（cappedコレクション）を一時受けとしたものを

構築しています。

1DB1コレクションで1mongod に数百のデータを持っています。

各コレクションは運用当初にデータ見積もりが難しいため、しばらく運用を

回してから、その実データを元にオンラインで処理を動かしながら、かつ、

capped設定（インデックスも付けているので＋インデックス設定）を変更

しようとしています。

荒っぽい使い方をしていることは重々承知しているのですが、同じような

ことを試された経験などあれば、その時どのようにシステムを考えられたか

など教えていただけると助かります。

ちなみに、この設定で回していた時、おそらくinsertとconvertが重なったりする

ことが原因ではないかと思っていますが、mongoが異常終了することがありま

した。

----- BEGIN BACKTRACE -----

...

 mongod(_ZN5mongo15printStackTraceERSo+0x32) [0x107b7b2]

 mongod(_ZN5mongo10logContextEPKc+0xE9) [0x1018c79]

 mongod(_ZN5mongo11msgassertedEiPKc+0xAE) [0xffd52e]

 mongod(+0xBFD5DC) [0xffd5dc]

 mongod(_ZN5mongo9DbMessage9nextJsObjEv+0x25D) [0xa96a9d]

 mongod(_ZN5mongo14receivedUpdateEPNS_16OperationContextERNS_7MessageERNS_5CurOpE+0x14C) [0xb61c2c]

 mongod(_ZN5mongo16assembleResponseEPNS_16OperationContextERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortE+0x16EA) [0xb65d5a]

 mongod(_ZN5mongo16MyMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE+0xF5) [0x8b2675]

 mongod(_ZN5mongo17PortMessageServer17handleIncomingMsgEPv+0x339) [0x102cfb9]

 libpthread.so.0(+0x7AA1) [0x7fb68e6d3aa1]

 libc.so.6(clone+0x6D) [0x7fb68d22493d]

-----  END BACKTRACE  -----

このシステムでは、クライアント側は、perl/python/c それぞれのドライバ

経由で接続しているものがあり、このメッセージがcappedと関連してのもの

かどうかは不明です。

一番やりたい理想形：

　1. 最初しばらくデータを溜める。

　2. バッチか何かで、データ数・データサイズを元に、1日分、などの

　　サイズを計算して、capped設定する。

　3. 日々データ数・データサイズをチェックして、1日分溜められてい

　　ない設定のものについては、再convertする。

　4. convert時もオンラインデータは受付可能とする。

いつも抽象的な質問で申し訳ありませんが、ご意見いただけると助かります。

[Hiroaki Kubota]

貯めたいデータのサイズが想定出来ない場合、１日分のデータを貯めるという仕様とcapped collection の仕様はマッチしません。
cappedにしたい理由が無ければ無理にcappedにしない方が幸せだと思いますがどうでしょう？

私なら最初にTTL index による自動削除機能を検討すると思います。
https://docs.mongodb.com/manual/tutorial/expire-data/

また、mongodが落ちる問題はmongodのバグなので、最低限バージョンと設定が示されないと何も助言できません。。

2016年5月2日 15:48 Nishimura Ryuichiro <nish...@gmail.com>:

--
このメールは Google グループのグループ「MongoDB JP」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには mongodb-jp+...@googlegroups.com にメールを送信してください。
このグループに投稿するには mongo...@googlegroups.com にメールを送信してください。
https://groups.google.com/group/mongodb-jp からこのグループにアクセスしてください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。

[Nishimura Ryuichiro]

crumbjp さん

いつも的確な助言ありがとうございます！

＞１日分のデータを貯めるという仕様とcapped collection の仕様はマッチしません。

そうなんですよね。自分でも方向性は違うと認識はしていながらも、一方では、それこそ

他のDBのようにサイズの設定ができるのもメリット、という認識であえてcappedに

挑んでいます。

＞私なら最初にTTL index による自動削除機能を検討すると思います。

TTLについては、マニュアル等では delete + insert なのでパフォーマンスが

悪い、とのことが記載されていたため、2番手に甘んじてました。

自分で確認した限り（ただし最近ではないんですが。）では、それほど心配ない程度

だった、と思っています。

ただし、今のアプリケーションでは、DATE型のデータを持っていない（binary時刻

は持っています）ので、そこの変更or追加と、あとはIndexが増える、というところが

クリアできれば、TTLの方がシンプルだと思います。

ゆくゆくはシャーディング、なども考える必要がある可能性も捨てきれず、ますます

TTLの方がいいのかと思います。

ありがとうございました。

西村

2016年5月10日火曜日 11時23分34秒 UTC+9 crumbjp: