「MongoDBアンチパターン」を聞いてきた！

DB Tech Showcase　東京2014つづき、

月間１０億PVから学んだMongoDBアンチパターン

を聞いてきたので、その内容をメモメモ

---

月間１０億PVから学んだMongoDBアンチパターン

ZenClerk(ぜんくらーく）０から１０億PV
・ベストタイミングオファー
　　パラメータ→機械学習

難しい点
・リアルタイム
・ビッグデータ
　　マウスの移動まで
　　月間１０億PV
　　秒間４００PV
　　同時接続数５万
　　月間１０TB保存

フロントエンド
　　あんぎゅらーJS
　　ROR
　　MySQL
　　めむきゃしゅD
　　AWS

ばっくえんど
　　Node.JS
　　Mongo
　　Socket.io
　　Redis

AWS　２２台
　i2.2Xlarge　８台
　m1.large
m3.large　　１２台
　r3.large　　２台

～１０００万PV→mongoDB
スケールしない
～１億
　replica set
書き込み、メモリ乗り切るか
シャーディング
　→３つのレプリカセット

ここまでアプリケーションの変更ほとんどなし
（一部クエリを最適化）

使った理由
・スキーマレス
・トランザクション不要（最低限のアトミック処理）
・柔軟なクエリ
・容易なスケールアウト
・node.jsとの相性のよさ→socket.ioを使う→JSON
本当の理由
・導入の容易さ→ホスティングサービス
・学習の容易さ（エンジニア以外にとっても）

ベストプラクティス
→むずかしい
・ドキュメントを埋め込む
　　読み込み重視：書き込み遅くなる
・ドキュメントを埋め込まない（RDBの正規化に近い）
・書き込みスケールする：読み込み２回
・ハイブリッド

スキーマレスはスキーマ定義が不要という意味ではない
RDBMSよりも選択肢が多く難しい

アンチパターン
インデックスへん
・インデックスの張りすぎ
　　メモリの使いかたがあまり賢くない
　→実際にはおそくなる：メモリに載らなくなれば
　プラガブルストレージエンジン
　　InnoDB,rocksDBに変えられる

・文字列のインデックス
インデックス
　RDBMSとほとんど同じ
　B-Tree
　メモリ効率悪い
　→時間はメモリ効率よい
→できるだけObjectIdを使う。

クエリへん
・フィールドを指定しないクエリ
　coverd indexを有効利用する

・コールドデータへのクエリ
　ホットデータへのアクセスは高速
　コールドデータのアクセスは遅い

・集計
　　要約データ５分、１時間、１日など
　ホットデータを意識したアクセス

・プライマリに偏った
　　レプリカセット
　　クエリを分散させることができる
　　プログラマが、セカンダリに投げるかどうか判断する
　　最新のデータ出なくても良いなら、読み込みをセカンダリへ

アップデートへん
・updateと&incを使って
・upsert:true

肥大化するドキュメント
MongoDBの苦手分野
　フィールドが肥大化するアップデートが遅い
　データの移動
　Redis（れでぃす）と組み合わせて使う
すべてをMongoでやろうとしない

あーきてくちゃ
・１つのDBに詰め込む
　　わけたほうがいい
　　メモリが多く使える
　document-level locking

３つの監視
・リアルタイム監視
　　MongoHQ
・見返すための監視
　　MMSダッシュボード
・遅いクエリの監視
　　explain(true)
１００ｍｓ以上かかったら危険信号