日本語：Mongo dbに於けるシャーディングについて
•Descargar como PPTX, PDF•
12 recomendaciones•5,202 vistas
MongoDBのシャーディング機能についての解説
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a 日本語：Mongo dbに於けるシャーディングについて
Similar a 日本語：Mongo dbに於けるシャーディングについて (20)
Más de ippei_suzuki
Más de ippei_suzuki (10)
Último
Último (10)
日本語：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