日本語：Mongo dbに於けるシャーディングについて
•Download as PPTX, PDF•
12 likes•5,206 views
MongoDBのシャーディング機能についての解説
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 日本語：Mongo dbに於けるシャーディングについて
Similar to 日本語：Mongo dbに於けるシャーディングについて (20)
More from ippei_suzuki
More from ippei_suzuki (10)
Recently uploaded
Recently uploaded (14)
日本語：Mongo dbに於けるシャーディングについて
- 1. #MongoDB MongoDBにおける シャーディングについて 鈴木いっぺい
- 2. アジェンダ • 顧客事例 • 性能/スケーリングを目的としたシャーディング – シャーディングを導入するタイミング – シャードをいくつ作ればいいのか？ • シャードの種類 • シャードキーの選び方 • シャードの性能以外の活用方法
- 3. 顧客事例
- 5. Foursquare • 5000万ユーザ • のべ60億回のチェックイン回数 (毎日600万回増かのペース). • 5500万箇所の位置情報 (レストラン、ショッピング等) • 170社の商店がマーケティングでこのプラットホ ームを利用 • 一秒あたりのオペレーション数: 300,000 • ドキュメント数: 55億件
- 6. Foursquare クラスター数 • 11個のMongoDBクラスター – 内、8つがシャーディング採用 • 最大のクラスターは15個のシャードを運用(チェ ックイン機能) – user idをシャードキーとして採用
- 7. CarFax • Large data set 中古自動車の履歴情報を提供 するSaaSベンダーの最大手
- 8. CarFax社でのシャード状況 • 130億以上のドキュメント数 – 毎年15億個のドキュメントが追加 • 自動車1大の履歴レポートは200以上のドキュメ ントを保有 • 12個のシャード • 9ノードのレプリカセット • レプリカは3カ所のデータセンタに分散 (次ページ）
- 10. CarFax NoSQL技術の評価の末にMongoDBを選択 以前の状況MongoDBの選択理由導入結果 • 自動車履歴データベー スの提供 • 130億個のレコード(毎 年15億個の増加ペース ） • 30前に導入したVMSベ ースのRDBMSシステム • 性能問題 • 維持費が高い • 性能が従来の4倍 • 安価な汎用サーバでスケ ールアウト • 多重化をサポート • フレキシブルで動的なス キーマデータモデル • データの同期性に強み • データ分析/アグリゲーシ ョン機能 • MongoDBを主データスト アに採用 • 50台のサーバ • 10個のシャード • シャード毎に5ノード のレプリカセット
- 11. シャーディングとは？
- 12. シャーディング概要 クエリー ルータ シャード１ プライマリ セカンダリ セカンダリ シャード２ プライマリ セカンダリ セカンダリ アプリ ドライバー シャード３ プライマリ セカンダリ セカンダリ シャード４ プライマリ セカンダリ セカンダリ … クエリー ルータ クエリー ルータ … …
- 13. 自動シャーディング シャード１ シャード２ シャード３ シャードN 水平スケール • ３種類のシャード：ハッシュベース、レンジベース、タ グ型 • キャパシティの増減を動的に変更 • 自動バランス
- 14. スケーリング：シャーディング キーレンジ 0..100 mongod Read/Write スケーラビリティ
- 15. スケーリング：シャーディング キーレンジ 0..50 キーレンジ 51..100 mongod mongod Read/Write スケーラビリティ
- 16. スケーリング：シャーディング キーレンジ 0..25 キーレンジ 26..50 キーレンジ 51..75 キーレンジ 76.. 100 mongod mongod mongod mongod Read/Write スケーラビリティ
- 18. サーバ／レプリカセットを見る... • データを保存するために十分なディ スク容量はあるか？ • クエリーのスループットが十分確保 されているか(ops/sec) • クエリー処理のレスポンスタイム
- 19. サーバ／レプリカセットを見る... サーバスペック ディスク容量 ディスクIOPS RAM ネットワーク ディスクIOPS RAM ネットワーク • データを保存するために十分なデ ィスク容量はあるか？ • クエリーのスループットが十分確 保されているか(ops/sec) • クエリー処理のレスポンスタイム
- 20. シャードの数はいくつ必要なのか？
- 21. ディスクスペース：必要なシャード数 の算定 • シャード全体に用意されているディスクスペース ＞ 必要なストレージ容量
- 22. ディスクスペース：必要なシャード数 の算定 • シャード全体に用意されているディスクスペー ス＞ 必要なストレージ容量 例： ストレージサイズ= 3 TB サーバのディスク容量= 2 TB シャードは２つ必要
- 23. RAM: 必要なシャード数の算定 • ワーキングセットがRAM内に収まる必要がある – シャード内のRAMの総合計> ワーキングセット • ワーキングセット= インデクス＋アクセスが頻繁 なドキュメントの合計 • RAM上にワーキングセットがあると➔ – レーテンシーが短い – スループットが高い
- 24. RAM: 必要なシャード数の算定 インデクスとワーキングセットのサイズの計測 db.stats() – 各コレクション内のインデクスサイズ db.serverStatus({ workingSet: 1}) – ワーキ ングサイズの算定
- 25. RAM: 必要なシャード数の算定 インデクスとワーキングセットのサイズの計測 db.stats() – 各コレクション内のインデクスサイズ db.serverStatus({ workingSet: 1}) – ワーキ ングサイズの算定 例： ワーキングセット= 428 GB サーバ上のRAM = 128 GB 428/128 = 3.34 4つのシャードが必要
- 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津のシャードが必要
- 31. シャーディングのタイプ
- 32. シャーディングのタイプ • レンジベース • タグベース • ハッシュ型
- 33. レンジベースシャーディング キー レンジ 0..25 キー レンジ 26..50 キー レンジ 51..75 キー レンジ 76.. 100 mongod mongod mongod mongod Read/Write スケーラビリティ
- 34. タグを利用したシャーディング mongod mongod mongod mongod シャード タグ シャードタグ開始終了 冬23 Dec 21 Mar 春22 Mar 21 Jun 夏21 Jun 23 Sep 秋24 Sep 22 Dec タグ レンジ 冬春夏秋
- 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
- 39. シャードキーの選び方
- 40. シャードキーとしての条件 • 良いシャードキーは: – 十分なカーディナリティ – 書き込みが分散してる – 一連のReadが特定のシャードにしぼられる("query isolation") • 殆どのクエリーでシャードキーを使う事が望ましい – 出ないと、全DB検索になる • 良いシャードキーを設定する事は重要！ – 性能とスケーラビリティに大きく影響 – 後からの変更は大変
- 41. カーディナリティの低いシャードキー • 巨大なチャンクを生む要因に • 悪い例：ブーリアン指数(True/False) Shard 1 mongos Shard 2 Shard 3 Shard N [ a, b )
- 42. シャードキーの値が単調に増加する • 単調増加するシャードキーの値は、インサート を特定のシャードに集中化させる • 例: タイムスタンプ, _idの値 Shard 1 mongos [ ISODate(…), $maxKey ) Shard 2 Shard 3 Shard N
- 43. シャードを採用する他の目的
- 44. シャードを採用する目的 • スケール対応 – データ量の増加 – クエリー数の増加 • ローカルWriteを維持しつつもグローバル展開 – 地域に分散したシャーディング • 階層型ストレージ • 早いバックアップ、リストア
- 45. グローバル実装／ローカルWrite プライマリ:NYC プライマリ:LON セカンダリ:NYC プライマリ:SYD セカンダリ:LON セカンダリ:NYC セカンダリ:SYD セカンダリ:LON セカンダリ:SYD
- 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
- 49. まとめ
- 50. シャード数の確定 • 必要なシャード数の算定には、次の要点を整理す る事 – ストレージの要求項目 – レイテンシー要求項目 – スループット要求項目 • 次のシステムの合計数値を求める事 – ディスク容量 – ディスクスループット – RAMの大きさ
- 51. シャーディングは次の目的に採用 • システムスケーラビリティ • 地域的に分散したクラスタの運用 • 階層型のストレージ • バックアップ／リストアのSLA向上
- 52. シャーディングに関する追加情報 • MongoDB マニュアル: http://docs.mongodb.org/manual/sharding/ • 関連ウェビナー: – How to Achieve Scale With MongoDB • ホワイトペーパー – MongoDB Performance Best Practices – MongoDB Architecture Guide
- 53. Thank You