More Related Content Similar to 日本語:Mongo dbに於けるシャーディングについて (20) More from ippei_suzuki (10) 日本語:Mongo dbに於けるシャーディングについて2. アジェンダ
• 顧客事例
• 性能/スケーリングを目的としたシャーディング
– シャーディングを導入するタイミング
– シャードをいくつ作ればいいのか?
• シャードの種類
• シャードキーの選び方
• シャードの性能以外の活用方法
5. Foursquare
• 5000万ユーザ
• のべ60億回のチェックイン回数
(毎日600万回増かのペース).
• 5500万箇所の位置情報
(レストラン、ショッピング等)
• 170社の商店がマーケティングでこのプラットホ
ームを利用
• 一秒あたりのオペレーション数: 300,000
• ドキュメント数: 55億件
6. Foursquare クラスター数
• 11個のMongoDBクラスター
– 内、8つがシャーディング採用
• 最大のクラスターは15個のシャードを運用(チェ
ックイン機能)
– user idをシャードキーとして採用
10. CarFax
NoSQL技術の評価の末にMongoDBを選択
以前の状況MongoDBの選択理由導入結果
• 自動車履歴データベー
スの提供
• 130億個のレコード(毎
年15億個の増加ペース
)
• 30前に導入したVMSベ
ースのRDBMSシステム
• 性能問題
• 維持費が高い
• 性能が従来の4倍
• 安価な汎用サーバでスケ
ールアウト
• 多重化をサポート
• フレキシブルで動的なス
キーマデータモデル
• データの同期性に強み
• データ分析/アグリゲーシ
ョン機能
• MongoDBを主データスト
アに採用
• 50台のサーバ
• 10個のシャード
• シャード毎に5ノード
のレプリカセット
12. シャーディング概要
クエリー
ルータ
シャード1
プライマリ
セカンダリ
セカンダリ
シャード2
プライマリ
セカンダリ
セカンダリ
アプリ
ドライバー
シャード3
プライマリ
セカンダリ
セカンダリ
シャード4
プライマリ
セカンダリ
セカンダリ
…
クエリー
ルータ
クエリー
ルータ
… …
23. RAM: 必要なシャード数の算定
• ワーキングセットがRAM内に収まる必要がある
– シャード内のRAMの総合計> ワーキングセット
• ワーキングセット= インデクス+アクセスが頻繁
なドキュメントの合計
• RAM上にワーキングセットがあると➔
– レーテンシーが短い
– スループットが高い
26. ディスクスループット: 必要なシャード
数の算定
• シャード間のIOPSの合計> 必要なIOPS以上必要
• IOPSの算定は容易では無い
– ドキュメントのアップデート
– インデクスのアップデート
– ジャーナルへのアペンド
– ログエントリー?
• ベストな方法– プロトタイプを作り実計測を行う
27. ディスクスループット: 必要なシャード
数の算定
•シャード間のIOPSの合計> 必要なIOPS以上必要
•IOPSの算定は容易では無い
–ドキュメントのアップデート
–インデクスのアップデート
–ジャーナルへのアペンド
–ログエントリー?
例:
必要なIOPS = 11000
サーバディスクIOPS =
5000
3つのシャードが必要
•ベストな方法– プロトタイプを作り実計測を行う
28. OPS: 必要なシャード数の算定
• S = 単一のサーバのops/sec
(一秒あたりのオペレーション数)
• G = 必要なops/sec
• N = シャードの数
• G = N * S * .7
N = G/.7S
29. OPS: 必要なシャード数の算定
• S = 単一のサーバのops/sec
(一秒あたりのオペレーション数)
• G = 必要なops/sec
• N = シャードの数
• G = N * S * .7
N = G/.7S
シャーディング処理のオーバヘッド
30. OPS: 必要なシャード数の算定
• S = 単一のサーバのops/sec
(一秒あたりのオペレーション数)
• G = 必要なops/sec
• N = シャードの数
• G = N * S * .7
N = G/.7S
例:
S = 4000
G = 10000
N = 3.57
4津のシャードが必要
33. レンジベースシャーディング
キー
レンジ
0..25
キー
レンジ
26..50
キー
レンジ
51..75
キー
レンジ
76.. 100
mongod mongod mongod mongod
Read/Write スケーラビリティ
35. ハッシュ型シャーディング
ハッシュ
レンジ
0000..4444
ハッシュ
レンジ
4445..8000
ハッシュ
レンジ
i8001..aaaa
ハッシュ
レンジ
aaab..ffff
mongod mongod mongod mongod
36. ハッシュ型シャードキー
• 利点:
– DBへの書き込みが等しく分散化
• 欠点:
– ランダムなデータやインデクスのアップデートはI/O
の負荷を高める可能性あり
– レンジベースのクエリーは全項目検索になる
Shard 1
mongos
Shard 2 Shard 3 Shard N
40. シャードキーとしての条件
• 良いシャードキーは:
– 十分なカーディナリティ
– 書き込みが分散してる
– 一連のReadが特定のシャードにしぼられる("query
isolation")
• 殆どのクエリーでシャードキーを使う事が望ましい
– 出ないと、全DB検索になる
• 良いシャードキーを設定する事は重要!
– 性能とスケーラビリティに大きく影響
– 後からの変更は大変
44. シャードを採用する目的
• スケール対応
– データ量の増加
– クエリー数の増加
• ローカルWriteを維持しつつもグローバル展開
– 地域に分散したシャーディング
• 階層型ストレージ
• 早いバックアップ、リストア
46. 階層型ストレージ
• ハードウェアコストの節約
• アクセス数の多いドキュメントを高速なサーバに
乗せる
– アクセス数の少ないドキュメントは性能の低いサーバ
に移動
• シャーディングでタグを利用する
現在現在過去過去
mongod mongod mongod mongod
SSD SSD HDD HDD
47. 早いデータ復元
• 40 TB データベース
• 2つのシャードで各々20TB保有
• 課題
– データ障害後のデータリストアSLAが満足できる性能
を確保できない
mongod mongod
20 TB 20 TB
48. 早いデータ復元
• 40 TB データベース
• 4つのシャードで各々のシャードで10TBずつ持た
せる
• ソリューション
– システムリストアに要する時間を50%削減
mongod mongod
10 TB 10 TB
mongod mongod
10 TB 10 TB
52. シャーディングに関する追加情報
• MongoDB マニュアル:
http://docs.mongodb.org/manual/sharding/
• 関連ウェビナー:
– How to Achieve Scale With MongoDB
• ホワイトペーパー
– MongoDB Performance Best Practices
– MongoDB Architecture Guide