Mongo DB Casual Talksに行ってきた

あんまりMongo DB Casual Talks のブログがないようなので、ざっくり書きます。

「MongoDBのアレをアレする」 by [twitter:@kuwa_tw] さん


  • クラスタが遅い1
    • 必要なデータを一気にインポート
    • oplogが許容範囲を超えてレプリケーションが停止
    • PrimaryShardにChunkが溜まってI/Oバウンドに
    • 負荷が高いのでBalancerは動かない
  • クラスタが遅い2
    • ShardするCollectionのShard設定漏れ
    • PrimaryShardでデータファイルが多くなりつづけてメモリマップドファイルのサイズをこえてI/Oバウンド
    • ShardしてないのでもちろんBalancerは動かない
      • 本当に突然パフォーマンスダウンする
      • PrimaryShardは余裕を持たせておく
      • Shard設定は定期的に確認、もしくはShardの設定を自動化する
  • バックアップ
    • mongos経由でAutoBalancingをoff
    • 各レプリカセットにfsync lock
    • 各mongodにmongodumpを実行してバックアップ取得
    • 各レプリカセットにfsync unlock
    • mongos経由でAutoBalancingをon
  • 障害時にみるもの
    • mongostat
      • faults : 1秒あたりのページフォルト数⇒メモリ増設もしくはサーバ増設
      • Locked% : グローバルライトロックの時間割合⇒クエリの見直し、もしくはクラスタを分ける
      • idx miss% : indexのヒット率の時間割合⇒クエリもしくはインデックスの見直し
      • qr|qw : 読み込みキュー|書き込みキューの大きさ⇒ロック増加 or クエリ増加
    • mongotop
      • アクセスが集中しているcollectionの確認
    • mongosniff
      • 最後の手段のパケットキャプチャ
      • mongosのアクセス状況、複雑のクエリを見る
    • db.adminCommand("connPoolStats")
      • Sharding環境におけるconnectionpoolの統計
    • db.serverStatus()
      • サーバの現在の状態の確認

恐らく国内では最大のMongoDBユーザであるCyberAgentさんの経験から得られる運用ノウハウ。
一つ一つはどこかで聞いた話ではあったが、まとめてあるとまだまだ色々問題ありますね。
カジュアルに100台運用はできません。
CAさんには、「今だからできる、MySQLを採用した場合とのコスト比較」とかやってほしい。
※ Fusion-io積んだMySQL10台でリプレイス可能とかだったら面白いのに。。

「Casual Compression on MongoDB」 by [twitter:@just_do_neet] さん


  • MongoDBの欠点
    • トランザクション未サポート
    • Global Lock
    • システムリソース（メモリ、ディスク）が肥大化
    • データ圧縮未対応（通信、データストア共に）
    • セキュリティ周りが弱い
  • MongoDBはHBase(Snappy圧縮)の三倍強のデータサイズ
  • BigDataを扱う環境にはあまり向かない
    • スケールするがゆえに、下手にそれなりの規模のシステムに導入するとサーバ無限増殖の刑に。。
  • フィールド名をできるだけ短く
    • BSONでデータを保持しているので、1つのドキュメントの中にフィールド情報を持つ
    • 複数のレコードが同一のフィールド名を持っていても、1レコード毎に情報を持つ
  • 特定のデータをbinary形式で保存
    • アプリケーション側で特定のフ複数のフィールドをまとめてシリアライズし、圧縮
      • 複数フィールドをMessagePackでシリアライズ＋圧縮で最大2/3に圧縮。
      • 圧縮・シリアライズのオーバヘッドに注意
      • 独自binary化すると後戻りできないので注意
  • 小さい正整数の整数符号化
    • 整数符号化で保存したら、Integerよりサイズが大きくなった。。


データサイズが大きくなりがちなMongoDBで、データ圧縮ができないかというアプローチ。
安定したパフォーマンスを出すために、データがメモリに乗り切る範囲で運用するというのは、
よくとられる手法なので、データ圧縮ができるとサーバが少なくてすむので貴重なお話。
最大で2/3程まで圧縮が可能であるが、圧縮したフィールドは検索に使えなくなるので、柔軟な検索が
できなくなる弊害があるなど、使用するにはアプリケーションの特性をよく見てからということですね。

「MongoさんをAWSへお迎えする」 by [twitter:@understeer] さん



  • スナップショットでバックアップ
    • mongodをFlush&Lock
      • db.fsyncLock();
    • Filesystemをfreeze
      • xfs_freeze -f /path/to/mongo
    • 各ボリュームのスナップショット取得
      • ec2-create-snapshot -d xxx vol-xxxx
    • FilesystemのunfreezeとMongodのUnlock
      • xfs_freeze -u /path/to/mongo
      • db.fsyncUnlock();
  • スナップショットからリストア
    • 各スナップショットからボリューム作成
      • ec2-create-volume-snapshot snap-xxxx
    • 各ボリュームをアタッチ
      • ec2-attach-volume-device /dev/sdf/vol-xxxx
    • RAID、LVM復旧、MongoDB起動
mongodbを使ってみたい by [twitter:@riywo] さん

MongoDBのクエリでMySQLを使えるO/Rマッパーを作った。MongoSQL

非常に意欲作です。

MongoDBによるカジュアルなタイムラインシステムの実装 by [twitter:@hito_asa] さん


MongoDBを利用したタイムラインシステムのおはなし
タイムライン機能を作る際のフォロワーのIDを取ってきて、さらにそのフォロワーのコンテンツを
取ってくると言った処理が重いのでなんとか簡単にしたい。

  • TimeLine Design
    • 有限長
    • 最新のみ保持
    • 追記のみ
    • 常に時系列での取得
    • 追記、取得が早い
      • ユーザ毎にCAPPED COLLECTION
  • 200万コレクションの世界
    • 普通では作れないので、nssizeを変更
    • データベースのコレクションの上限が60万なので、上限に達したら新たなデータベースを作成
      • すぐSWAPする
      • mongoコンソールがsuggestで落ちる
      • GLOBAL LOCKのため、コレクションの削除で止まる
      • 応答時間が安定しない
  • 教訓
    • コレクションはたくさん作らない
    • 1インスタンスでたくさんDBを作らない
    • シビアな応答性能を求めない
    • MongoDBをカジュアルに導入しない

個人的には一番面白かった発表。是非、この路線で突っ走って貰いたい。
CAPPED COLLECTIONは、TIMELINE機能で欲しい機能のいくつかを持っているので、うまいこと
機能拡張してくれると面白そう。

カジュアルにMongoDBのBackup機能説明 by [twitter:@matsukaz] さん



  • mongexportはJSON/CSV形式でデータを出力
    • 全てのデータ型をサポートしているわけではない
      • data_binary
      • data_date
      • data_timestamp
      • data_regex
      • data_oid
      • data_ref
  • mongodumpはBSON形式でデータを出力
    • データは正しい情報のまま
    • Onlineでの実行も可能
      • 実行中はパフォーマンスに影響あり
    • ただし、小規模での利用を想定したもの
      • データは一箇所に出力される
  • officialなバックアップ手順
    • balancerを止める
    • 全PrimaryをLock
    • config情報をBackup
    • SecondaryのデータをBackup
    • 全PrimaryをUnlock
    • balancerを有効化
      • 欠点として、Lock時間が長くかかる
  • Lock時間を短くしたバージョン
    • balancerを止める
    • 全PrimaryをLock
    • config情報をBackup
    • Secondaryを落とす
    • 全PrimaryをUnlock
    • balancerを有効化
    • 落としたSecondaryをBackup
    • 落としたSecondaryを起動

うん。SecondaryをLockして、バックアップを取ろう。

カジュアルにソースコードリーディング by [twitter:@choplin ] さん



MongoDBソースコードリーディングの成果の発表。

  • 追記型
    • 更新を削除と挿入の組み合わせで実現する
    • 同時制御の処理が簡潔
    • データ容量が肥大
    • 書き込み処理の負荷
    • ガベージの発生
  • In-place Update
    • 既存のサイズを超えない場合、ドキュメントまるごとの追記を行わず、必要な値のみ書き換える
  • Padding Factor
    • In-place Updateを行うために予め、Padding領域を確保する。
      • どれだけPaddingするかのfactor
    • Default 1.0
    • Min 1.0、Max 2.0
    • Update + 0.6
    • Insert / (In-place Update?) -0.01
CasualなMongoDBのサービス運用Tips by [twitter:@nsega] さん


MongoDBを1年間運用して得たTipsを惜しまず出します。

  • Tips1:定期的な計測
    • Collection/Document数
      • db.usercollection.find.count()
      • db.usercollection.stats()
    • Shardingの偏り
      • printSahrdingSize()
    • Disk使用状況の把握
    • df -hT
  • Tips2:定期的なバックアップ
    • 停止可能な場合は、データファイルをコピーすればOK
    • 停止不可の場合は、Secondaryからバックアップ
  • Tips3:定期的なデータ最適化
    • 定期的にReparDatabaseコマンドを実施
      • mongod --repair
      • db.repariDatabase
  • Tips4:定期的なバージョンアップ
    • 性能、機能改善
    • バグfix
Casual Sucks by [twitter:@repeatedly] さん

資料はこちら

  • oplogには限界がある
    • oplog collectionはcapped collectionなので、sizeの制約がある。それを超えると。。。
  • マスターマスターで片方のデータが一瞬消える
  • クライアントの実装アプローチが違う
mongoengineでカジュアルな有向グラフ by [twitter:@bibrost] さん
  • MongoEngineを使って、カジュアルに有向グラフを扱えるPythonライブラリ作ったよ。(mongo-directedgraph)
  • MongoDBはスモールデータを扱うには、よい選択。ミドルやビッグを扱うとダメ
mongodbとfluentdの素敵な関係 by [twitter:@stanaka] さん
  • Fluentd+MongoDBでログ流してる
  • システム間を疎結合にするために、ファイルに一度出力してtail
  • タグを変えて流し直すことができるので、超便利

所感

バックアップの話が多かったのは、人柱精神溢れるMongoな人たちの運用実績が確実に増えてるということでしょう。
MongoDBの由来となったhumongous（ばかでかい）という言葉なんて、誰も知らないかのように、スモールデータで
やめとけといった話が多く出たのが印象的でした。（私も使うのであれば、スモールデータ限定で使いますが。）

風邪気味で懇親会に出れなかったのが若干心残りでしたが、次の機会に。