Download as PDF, PPTX
![name: Yuji Isobe
attributes: [
engineer
consultant
security specialist
startup member
of
]](https://image.slidesharecdn.com/10pvmongodb-140513204745-phpapp02/75/10-pv-mongo-db-2-2048.jpg)
![back_ends: [
Node.js
CoffeeScript
MongoDB
Redis
AWS
]
front_ends: [
Nginx
Ruby on Rails
MySQL
memcached
AWS
]
architecture:](https://image.slidesharecdn.com/10pvmongodb-140513204745-phpapp02/75/10-pv-mongo-db-8-2048.jpg)
![back_ends: [
Node.js
CoffeeScript
MongoDB
Redis
AWS
]
front_ends: [
Nginx
Ruby on Rails
MySQL
memcached
AWS
]
architecture:](https://image.slidesharecdn.com/10pvmongodb-140513204745-phpapp02/75/10-pv-mongo-db-9-2048.jpg)
![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](https://image.slidesharecdn.com/10pvmongodb-140513204745-phpapp02/75/10-pv-mongo-db-37-2048.jpg)
![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](https://image.slidesharecdn.com/10pvmongodb-140513204745-phpapp02/75/10-pv-mongo-db-39-2048.jpg)
![[C33] 24時間365日「本当に」止まらないデータベースシステムの導入 ～AlwaysOn＋Qシステムで完全無停止運用～ by Nobuyuki Sa...](https://cdn.slidesharecdn.com/ss_thumbnails/c33sqlserversasaki-131128193643-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[大図解]ピグライフはこう動いている](https://cdn.slidesharecdn.com/ss_thumbnails/pigglifegreexca-110817005057-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
月間10億pvを支えるmongo db
- 1.
- 2. name: Yuji Isobe attributes:[ engineer consultant security specialist startup member of ]
- 3. -> 2年間で月間10億PVを支える まで成長した の 「泥臭い」負荷対策をお話します ->あるある紹介 -> 今はまだ問題点を洗い出している段階 ベストプラクティスがあれば教えて欲しい goals:
- 5.
- 6.
- 7. -> 合計月間PV10億 -> 秒間平均400PV ->平均同時接続数5万 -> 月間保存データ量10TB db. .stats()
- 8. back_ends: [ Node.js CoffeeScript MongoDB Redis AWS ] front_ends: [ Nginx Rubyon Rails MySQL memcached AWS ] architecture:
- 9. back_ends: [ Node.js CoffeeScript MongoDB Redis AWS ] front_ends: [ Nginx Rubyon Rails MySQL memcached AWS ] architecture:
- 10. we.use( ).explain() -> スキーマレス ->安定した書き込み -> 柔軟なクエリ -> 容易なスケールアウト -> との相性の良さ
- 11. 月間10億PVへの道のり -> ∼3000万PV -> 3000万∼1億PV ->1億∼3億PV -> 3億∼10億PV -> 継続的な監視
- 12.
- 13. -> メモリ上に乗れば高速 -> 1クエリにつき1インデックス ->B-Treeのバランスが重要 インデックスを理解する
- 14. -> メモリ上に乗れば高速 -> 1クエリにつき1インデックス ->B-Treeのバランスが重要 インデックスを理解する From 2.6.0
- 15.
- 16. user = newmongoose.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 = newmongoose.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.
- 19.
- 20.
- 21.
- 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.
- 25.
- 26.
- 27.
- 28.
- 29. Schema Design atScale http://www.mongodb.com/presentations/schema-design-scale-1
- 30.
- 31. -> にバッファする -> BulkInserts/Operationsを使う 書き込みの回数を減らす
- 32. -> にバッファする -> BulkInserts/Operationsを使う 書き込みの回数を減らす From 2.6.0
- 33.
- 34. -> オンメモリ型のKVS -> データ型が豊富 ->リスト・セット・ハッシュ -> の苦手分野を補う
- 35.
- 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
- 38.
- 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
- 40.
- 41.
- 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にバックアップ -> 統計データを保存 ->定期的な自動削除 古いデータを削除する
- 47.
- 48.
- 49. -> メモリは積めば積む程早くなる -> ディスクアクセスも早い方が良い ->SSDを使いましょう チューニング
- 50.
- 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 主に使用しているインスタンス
- 53.
- 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 遅いクエリの監視
- 59.
- 60. -> インデックスの仕組みを理解する -> 書き込みの回数を減らす ->DBを用途別に分ける -> メモリを増やす -> 継続的に監視する my.presenation.aggregate()
- 61.
- 62.