Mongo DB Casual Talksに参加してきました
渋谷のDeNAさんで開催されたMongo DB Casual Talksに参加してきました。業界用語で言うところのカジュアルにふさわしい、ガチの勉強会でした。
MongoDBのアレ
- MongoDBはクラスタリングやシャーディングが自動的なのが魅力
- ただしシャード設定の不備があると、本当に突然パフォーマンスがダウンする
- バックアップはオートバランスを停止してから
- ロックがグローバルなのに注意
- 障害・ログ
- mogostat
- faultが多い場合はメモリ不足の可能性あり
- Locked%が高い場合は書き込みを分ける
- qr|qwもロックの可能性を疑うこと
- mogostat
- mongosniff
- 複雑なクエリなどを見るときに
- Loglevel変更は動的にできるので、何かあった時にあげるといい
「みんなもカジュアルに100シャード運用してみよう!」
Casual Compression onMongoDB
- 「今日はデータ圧縮の話をします」
- トランザクションは甘え
- 標準ではデータ圧縮未サポート
- カジュアルに圧縮
- レコードひとつひとつフィールド名がある→短くすればサイズ短縮可能
- OR Mapperをつかってサポート
- 圧縮・伸張の早いアルゴリズムを使う
- シリアライズはMessagePack
- 効果はあるが副作用も大きい
「大きいデータ扱うならHBaseがおすすめ」
AWSでMongoDB
LT2 mogodbでカジュアルなタイムラインの実装(資料)
- 実際にサービスで使っているもの
- MySQLで重くなるものをMongoDBで
- スキーマは残念
- CappedCollectionが最適→無駄にコレクションが増える→限界がすぐ来る→DBがたくさん→止まりまくり(^^;)
「Mongoはカジュアルに導入しない」
LT3 カジュアルに非公式データパックアップ(資料)
- Mongoexportはデータが壊れる
- Mongodumpはデータが大量に出てしまう
- データ量が多いとリストアも大変
- とりあえずsecondaryを落としてみると意外と早い?
- lockした方がいいかも?
LT4 アーキテクチャ的な何か(資料)
- 追記型のメリットデメリット
- 書き込み周りがシンプル
- 代わりにゴミが増える、インデックスの更新などのデメリット
- 追記を避ける為にpadding facter
- insert以外で増える
LT5 カジュアルなMongo dbの運用
- 一年サービス運用した経験から
- 定期的なチェック重要
- シャーディングの偏りチェック等
- バックアップ
- 定期的な最適化
- ただし時間がかかるので注意
- V2系からコレクション単位で最適化
- ただし物理サイズは減らない