MongoDB Casual Talksに参加してきたよ
スライド
- Casual Complression on MongoDB - @just_do_neet
- MongoDBによるカジュアルなタイムラインシステムの実装 - @hito_asa
- カジュアルに非公式データバックアップ - @matsukaz
- カジュアルにソースコードリーディング - @choplin
- CasualなMongoDBのサービス運用Tips - @nesega
カジュアルなわけ無いと思ったけどカジュアルじゃないどころかガチュアルだった。全部ガチ。
とりあえず「MongoDBはデータ肥大するくせに圧縮未サポートなので使い手側がなんか工夫する必要があるよ」ってのと「シャードの設定ミスると突然の死を迎える」ということらしい。
試しに動かしてみた、程度のアレしか無いけど、たしかにインストールとかも含め、使い始める敷居は凄い低い。ただし運用(バックアップとかデータ量肥大)はいろいろハマりどころがあるのね、というところ。
Main Talks
Casual Complression on MongoDB - @just_do_neet
- MongoDBの課題
- MongoDBはオワコン？
- トランザクション未サポート
- Global Lock
- メモリ、ディスク食い
- データ圧縮未対応
- セキュリティ周りが弱い
- MongoDBはオワコン？
- MongoDBでのデータ圧縮
- MongoDBはデータも経路も圧縮を未サポート
- MongoDBはHBase(snappy圧縮時)の三倍強
- BigDataを扱う環境には向かない
- サーバ無限増殖
- フィールド名を出来るだけ短くする
- BSONは1つのドキュメントの中にフィールド名を持つ
- 複数のレコードが同一のフィールド名を持っていてもそれぞれのドキュメントがフィールド名を持っている
- フィールド名を数文字から1文字にしてみたら100万レコードで数MB変わってくる
- ORMで名前が短すぎる弊害はある程度抑制できる
- JavaではMorphiaがおすすめ
- SpringDataは重厚すぎる気がする
- 特定のデータをbinaryで保存
- 小さい正整数を符号化
- BSONの仕様上integerが一番小さい
- フィールド名短縮 > binaryで圧縮 >>>> |忘れてください| >>>> 正整数を符号化
- BSONの仕様上integerが一番小さい
- まとめ
- カジュアルな工夫で多少はデータサイズ肥大を抑制できる
MongoDBのアレをアレする - @kuwa_tw
- ピグライフはMongoDB
- 冗長化
- ReplicaSets
- 相互死活監視&投票により冗長性を保つ
- ReplicaSets
- スケーラビリティ
- Sharding
- データをchunkごとの細かい粒度に分割し、各mongodに渡す
- Sharding
- 冗長化
- アプリ側の実装コストを軽くしつつスケーラビリティを保ったシステムを手軽に使える
- サーバレベルの細かなチューニングはいらない
- サーバをMongoに合わせていく
- バックアップ
- mongodump
- バックアップはmongodumpで。でも稼働中にやるとダメなことになる
- mongos1経由でauto balancingをoff
- 各レプリカセットにfsync lockをかける
- 各mongodにmongodumpを実行してデータ取得
- 各レプリカセットにfsync unlock
- mongos経由でauto balancingをon
- mongodump
- mongostato - 見るべき項目
- mongotop
- 現在重いmongodを見たりする
- mtopはあまり使わない
- mongosniff
- パケットキャプチャ
- なんかあった際のアクセス状況の確認が可能
- mongosのアクセス状況とか、複雑なクエリを見たい場合
- ログレベルを上げたり下げたり
- 動的に出来る
- ログレベル5にすると1日で5GB出たりする
- db.serverStatus()
- サーバの現在の状態の確認
- mongostatとか各種
- db.currentOp()
- MySQLのSHOW PROCESSLIST相当
AWSでMongoDB - @understeer
- MongoDB on AWSで気になること
- 性能
- 運用管理
- 可用性、耐久性
- ディスクの性能
- ディスクの運用管理
- EBSとスナップショット
- コマンド一発でディスクイメージのスナップショットをスパっと取れる
- スナップショットでバックアップ
- mongodをflush & lock db.fsyncLock();
- 必要なら FileSystemをFreeze
- 各ボリュームのスナップショットを取得
- FileSystemのunFreezeとMongodのunlock
- 可用性、耐久性
- データをなくさないために
- ReplicaSetとってもDCごと死んだら死ぬ
- ゾーンをまたいでレプリカセットを組む
LT
mongodbを使ってみたい - @riywo
- MongoDBはクソ
- joinが出来ない
- トランザクションがない
- クエリ表現は好き
- なのでMongoDBのクエリっぽい表現でMySQLを操作できるお遊びモジュール作った
- ロードマップ
- リーダブルコードじゃないので書き直したい
MongoDBによるカジュアルなタイムラインシステムの実装 - @hito_asa
- コレクション作り過ぎると死ぬ
- 1インスタンスにDB作りすぎると死ぬ
- 応答性能が安定しない
- カジュアルに導入しない
カジュアルに非公式データバックアップ - @matsukaz
- mongoexport
- 全てのデータ型をサポートしない
- 一部のデータ型が失われるのでimportするとデータ型が失われる可能性があるのでmongoexportはよくない
- 全てのデータ型をサポートしない
- mongodump
- データ型までリストアできるが小規模な運用を想定している
- restoreにも時間がかかる
- restore後のマイグレーションにも時間がかかる
- mongodを落としてやればいいんじゃね？
- secondaryを落としてprimaryを即unlock。
- そしたらsecondaryをバックアップ、ということもできるよ。
- カジュアルに検証した限りには問題なし。問題が起きても知りませんよ
カジュアルにソースコードリーディング - @choplin
- MongoDBの更新系は追記型だが追記をなるべく避けるために、in-place updateを利用している
- 既存のデータサイズを超えない場合は既存のデータを更新
- 超える場合は既存データを削除(delete)した後、新規データを追記(insert)する
CasualなMongoDBのサービス運用Tips - @nesega
- MongoDBを運用して満一年の運用tips
- SNS機能の更新頻度が高いデータ(いいね、とか)
- Tips1 - 定期的な計測
- Collection/DOcument数の増減
- Shardingの偏り
- Disk利用状況
- Tips2 - バックアップ
- SecondalyをLockしてdump
- Tips3 - 最適化
- RepairDatabaseコマンドを定期的に実行している。
- mongod --repairもしくはdb.repairDatabase()
- Diskサイズが縮小する。Insert/Deleteしまくるなら効果でかい。
- Index最適化の効果も。ただし時間がかかる全データが対象だから。
- サーバにその時点のデータファイルサイズ以上の空き容量がないとエラーになる。
- メンテ時間を用意できなければ難しい
- v2からコレクション単位で最適化可能。
- db.collection.compact()。ただしこれだとdisk容量は減らない。
- Tips4 - 定期的なバージョンアップ
- v1.8 -> v2.0
- 性能、機能改善、バグフィックスなど
- Global write lockがかなり改善
- 運用を想定したデータストアの設計をすれば安定稼働は可能
- 愛用者には人柱精神が旺盛な人が多い
Casual Sucks - @repeatedly
mongoengineでカジュアルな有向グラフ - @bibrost
