![name: Yuji Isobe
attributes: [
engineer
consultant
security specialist
startup member
of
]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 月間10億pvを支えるmongo db
Similar to 月間10億pvを支えるmongo db (20)
月間10億pvを支えるmongo db
- 2. name: Yuji Isobe attributes: [ engineer consultant security specialist startup member of ]
- 3. -> 2年間で月間10億PVを支える まで成長した の 「泥臭い」負荷対策をお話します -> あるある紹介 -> 今はまだ問題点を洗い出している段階 ベストプラクティスがあれば教えて欲しい goals:
- 5. 大量データ
- 7. -> 合計月間PV10億 -> 秒間平均400PV -> 平均同時接続数5万 -> 月間保存データ量10TB db. .stats()
- 8. back_ends: [ Node.js CoffeeScript MongoDB Redis AWS ] front_ends: [ Nginx Ruby on Rails MySQL memcached AWS ] architecture:
- 9. back_ends: [ Node.js CoffeeScript MongoDB Redis AWS ] front_ends: [ Nginx Ruby on Rails MySQL memcached AWS ] architecture:
- 10. we.use( ).explain() -> スキーマレス -> 安定した書き込み -> 柔軟なクエリ -> 容易なスケールアウト -> との相性の良さ
- 11. 月間10億PVへの道のり -> ∼3000万PV -> 3000万∼1億PV -> 1億∼3億PV -> 3億∼10億PV -> 継続的な監視
- 13. -> メモリ上に乗れば高速 -> 1クエリにつき1インデックス -> B-Treeのバランスが重要 インデックスを理解する
- 14. -> メモリ上に乗れば高速 -> 1クエリにつき1インデックス -> B-Treeのバランスが重要 インデックスを理解する From 2.6.0
- 15. メモリ上に乗れば高速
- 16. user = new mongoose.Schema first: {type: String, required: true, index: true} last: {type: String, required: true, index: true} city: {type: String, required: true, index: true} ... created_at: {type: Date, default: Date.now, index: true} 書き込みが犠牲になっても読み込みが早ければいいじゃん！ Before
- 17. user = new mongoose.Schema first: {type: String, required: true} last: {type: String, required: true} city: {type: String, required: true} ... created_at: {type: Date, default: Date.now, index: true} 書き込みが犠牲になっても読み込みが早ければいいじゃん！ After
- 18. メモリ上に乗らなければ遅くなる
- 21. db.users.ensureIndex({first:1}); db.users.ensureIndex({last:1}); db.users.ensureIndex({ first:1, last:1 }); index intersection compound index vs. -> 複数の検索条件を 組み合わせたインデックス -> 2つのインデックスを使った 検索結果の共通部分を返す {first: Yuji , last: Isobe , city: Osaka } From 2.6.0
- 22. db.users.ensureIndex({first:1}); db.users.ensureIndex({last:1}); db.users.ensureIndex({ first:1, last:1 }); index intersection compound index vs. -> 複数の検索条件を 組み合わせたインデックス -> 2つのインデックスを使った 検索結果の共通部分を返す {first: Yuji , last: Isobe , city: Osaka } From 2.6.0 このクエリを早くしたい
- 23. db.users.ensureIndex({first:1}); db.users.ensureIndex({last:1}); db.users.ensureIndex({ first:1, last:1 }); index intersection compound index vs. メリット -> 同時にいくつでも デメリット -> 用途は限定的 メリット -> 柔軟な用途 デメリット -> 現在は同時に2つまで 2.6.0以降は 消してしまっても いいかも知れません From 2.6.0
- 24. B-Treeのバランスが重要
- 29. Schema Design at Scale http://www.mongodb.com/presentations/schema-design-scale-1
- 31. -> にバッファする -> Bulk Inserts/Operationsを使う 書き込みの回数を減らす
- 32. -> にバッファする -> Bulk Inserts/Operationsを使う 書き込みの回数を減らす From 2.6.0
- 33. にバッファする
- 34. -> オンメモリ型のKVS -> データ型が豊富 -> リスト・セット・ハッシュ -> の苦手分野を補う
- 36. without db.col.update({_id: 1}, {$push: {data: {x: 151, y: 100, ...}}); db.col.update({_id: 1}, {$push: {data: {x: 151, y: 179, ...}}); db.col.update({_id: 1}, {$push: {data: {x: 151, y: 266, ...}}); db.col.update({_id: 1}, {$push: {data: {x: 151, y: 295, ...}}); db.col.update({_id: 1}, {$push: {data: {x: 151, y: 322, ...}}); db.col.update({_id: 1}, {$push: {data: {x: 151, y: 333, ...}}); db.col.update({_id: 1}, {$push: {data: {x: 151, y: 340, ...}}); ...
- 37. db.col.insert({data: [ {x: 151, y: 100, ...}, {x: 151, y: 179, ...}, {x: 151, y: 266, ...}, {x: 151, y: 295, ...}, {x: 151, y: 322, ...}, {x: 151, y: 333, ...}, {x: 151, y: 340, ...}, ... ]}); with
- 39. db.col.insert([ {first: Yuji , last: Isobe , city: Osaka }, {first: Yuji , last: Isobe , city: Tokyo } ]); 使い方 var bulk = db.col.intializeOrderedBulkOp() bulk.find({first: Yuji }) .updateOne({$set: {city: Tokyo }}); Bulk Inserts Bulk Operations From 2.6.0
- 42. -> 用途ごとにDBを分ける -> Hotデータ/Coldデータを分ける -> 古くなったデータを削除する DB設計
- 43. -> Reader-Writerロックが使われている -> 2.2.0以降はDB単位でロックする -> マシンを分ければメモリが増える なぜDBを分けるのか？
- 44. -> メインデータ（Hot） -> メインデータ（Cold） -> 生データ -> 統計データ -> サイトデータ におけるDBの用途
- 45. -> Hotデータのロックを避ける -> Hotデータ用に大容量メモリ -> Coldデータ用に大容量ストレージ Hotデータ/Coldデータを分ける
- 46. -> S3にバックアップ -> 統計データを保存 -> 定期的な自動削除 古いデータを削除する
- 49. -> メモリは積めば積む程早くなる -> ディスクアクセスも早い方が良い -> SSDを使いましょう チューニング
- 51. 一般的な目的（m3） -> 最初に選ぶインスタンス メモリの最適化（r3） -> メモリとCPUのバランスが良い ストレージの最適化（i2/hs） -> SSDを使用。高負荷に耐えられる EC2インスタンスの選び方
- 52. r3.2xlarge -> vCPU: 8 -> Memory: 61GiB -> SSD: 160GB -> Cost: $0.840 per Hour i2.2xlarge -> vCPU: 8 -> Memory: 61GiB -> SSD: 800GB x 2 -> Cost: $2.001 per Hour 主に使用しているインスタンス
- 55. -> ホスティングサービスの ダッシュボード -> 毎日の健康チェック用 -> 過去の情報は参照できない -> メリット・デメリットは下記参照 ホスティングサービスで始めるMongoDB http://www.slideshare.net/yujiosaka/starting-mongo-db-on-hosting-services
- 57. -> 定期的な健康診断用 -> リアルタイム監視はMongoHQ 過去の状態チェックはMMS -> アラートとバックアップもあり -> 導入が簡単なので、 とりあえず入れておくべき
- 58. -> explain(true) -> system.profile.find() -> MongoDB professor -> Dex -> MongoHQ Slow Queries 遅いクエリの監視
- 60. -> インデックスの仕組みを理解する -> 書き込みの回数を減らす -> DBを用途別に分ける -> メモリを増やす -> 継続的に監視する my.presenation.aggregate()
- 62. any?.questions?