11〜12章は今までと少し趣の異なる並列化の話
DBを適用する上でのポイント
- サイズ/性能に余裕を持たせる必要
- (なぜここでこういう話が?)
- DBが大きくなれば、アクセス頻度も上がる傾向にある
- 対策として、キャッシュ等があるが、ログがあるのでディスクアクセスはどうしても発生する
スケーラビリティを上げるための幾つかの手段
- ストライピング … 複数のディスクにデータを分散させる
- I/Oボードの機能の使用
- 書き込み速度を向上させるI/Oボードがあるらしい
- キャッシュを行うが、電源断が起きても書き出すことができる
- CPU/メモリの強化
スケールアップとスケールアウト
- スケールアップ(垂直スケール) … コンピュータの処理性能を上げる
- スケールアウト(水平スケール) … 複数のコンピューターで分散処理する
- 本章ではこちらを紹介
http/アプリケーションサーバーはそれぞれの処理に関連が無いので簡単
- (セッションをメモリ内で管理してる等をしてなければ…!)
DBはサーバー間での連動が必要になってくる
- 他のDBサーバーからデータを取ってくる等
方法1: アプリケーションが処理
- 長所: DBに特別な仕組みが不要
- 短所: アプリケーションがデータ配置を知っている必要がある
方法2: 専用サーバーを利用する
- 手順
- 「マスターノード(本書ではCノード)」がSQLを分解
- 分解したSQLを「スレーブノード(本書ではSノード)」が実行
- 「マスターノード」が結果を集約
- 例: pgpool-II ?
- 長所: システム構成に依存しない
- 短所: 専用ソフトが必要
方法3: DBMS自身が対応する
- DBMS自身がデータを分散して配置する
- 例: MySQL Cluster、PostgreSQL の FDW(9.3〜?)等を活用、等
- 長所: システム構成に依存しない (アプリケーションは)
- 短所: DBMS全体の改造が必要 (DBMS自身が対応している必要がある)
並列処理が可能
- 単純なクエリ
- 結合等が非常に速くなる可能性
- 例: 100万x100万の演算 → 5台分散で20万×20万の演算
- 結合する対象がノードをまたがると逆に遅くなる恐れ
- (依存関係がツリー構造であれば、ここら辺はうまく行く)
- (いわゆる「集約」パターンになっていれば…)
範囲分割法 (図11.7)
- カラムの値(IDの下一桁等)でノードを分割する
データ分割のマッチングが悪い場合の対応方法 (図11.6)
- Cノードが全てのテーブルの値を集めて集約する
- Sノードが他のSノードから値を取得する
- 最適な取得方法は状況次第で、最適解を出すためには統計情報を持っておく必要がある
図参照