Location via proxy:
[ UP ]
[Report a bug]
[Manage cookies]
No cookies
No scripts
No ads
No referrer
Show this form
Submit Search
月間10億pvを支えるmongo db
•
98 likes
•
20,698 views
Yuji Isobe
Follow
1 of 62
Download now
Downloaded 93 times
More Related Content
月間10億pvを支えるmongo db
1.
月間10億PVを 支えるMongoDB speaker: Yuji Isobe
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 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 -> 継続的な監視
12.
∼3000万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.
メモリ上に乗らなければ遅くなる
19.
プログラムからフィールドを削除 したが、インデックスを消し忘れ、 無駄なインデックスが残る… スキーマレスあるある
20.
1クエリにつき1インデックス From 2.6.0
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のバランスが重要
25.
-> インデックスにB-Treeを採用 -> B-Treeは常に平衡を保っている インデックスの構造
26.
文字列のインデックス -> Hotデータが分散 -> メモリ効率が悪い
27.
ObjectId・時間のインデックス -> Hotデータが集中 -> メモリ効率が良い
28.
できるだけObjectIdを使いましょう 後からの変更は大変です(経験談) 教訓
29.
Schema Design at
Scale http://www.mongodb.com/presentations/schema-design-scale-1
30.
3000万∼1億PV 書 込 み は 一 度 だ け
31.
-> にバッファする -> Bulk
Inserts/Operationsを使う 書き込みの回数を減らす
32.
-> にバッファする -> Bulk
Inserts/Operationsを使う 書き込みの回数を減らす From 2.6.0
33.
にバッファする
34.
-> オンメモリ型のKVS -> データ型が豊富 ->
リスト・セット・ハッシュ -> の苦手分野を補う
35.
-> は肥大化するデータの Updateは遅い -> はオンメモリ型のため リストの操作が早い の苦手分野
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.
Bulk Inserts/Operationsを使う From 2.6.0
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.
MongoDBは開発スピードが早く、 パフォーマンス向上機能が次々と 出るので、積極的に使いましょう 豆知識
41.
1億∼3億PV mongod mongod mongod mongod mongod mongod mongod mongod mongod mongod
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.
クエリの条件をタイプミスして インデックスを使うことができず MongoDB死亡… スキーマレスあるある
48.
3億∼10億PV メ モ リ が 欲 し い で す
49.
-> メモリは積めば積む程早くなる -> ディスクアクセスも早い方が良い ->
SSDを使いましょう チューニング
50.
EC2インスタンスの選び方 http://blog.mongodirector.com/mongodb-on-aws-how-to-choose-the-right-ec2-instance-type-for-your-mongodb-server/
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.
ObjectIdを使ったクエリの実行に 100ms以上かかったら危険信号です 豆知識
60.
-> インデックスの仕組みを理解する -> 書き込みの回数を減らす ->
DBを用途別に分ける -> メモリを増やす -> 継続的に監視する my.presenation.aggregate()
61.
my.presentation .end thank you
;)
62.
any?.questions?
Download