負荷分散
分散問い合わせの種類
1.ラウンドロビン
ただ単に順番に見に行っているだけ
単純な振り分けなのでCPUを使わないが、すべてのSlaveに完全なデータセットが必要
2.重み付けラウンドロビン
単純な振り分けだが、ハードウェアの性能に差がある場合などに有効。
これもすべてのSlaveに完全なデータセットが必要になる。
3.接続数最小
振り分け対象のサーバの中で一番現在の接続数が最小のものを選択してリクエストする。
リソース消費が少ないと思われるサーバを使用できるが、これもSlaveで完全なデータセットが必要であり、AP側でDBの接続数を聞きにいかなければいけない。
4.応答時間最短
定期的に各サーバへの応答時間をテスト用のリクエストで計測してその時間が最小のサーバに寄せていく振り方。
実際に計測した時間で重み付けされるので、性能の違うサーバが並んでいてもレスポンスが標準化される。
直近のテスト結果をストアしておく必要がある。
5.AP-DBサーバ固定
対応するAPサーバが処理するときに必要なデータのサブセットのみがDBサーバにあればいい。
対応するAPサーバ以外は対応するDBサーバを利用できないため、上位での分け方を行わないとリソース消費に偏りが出る。
6.リスト
問い合わせ対象のデータによってリストからw欄だサーバに問い合わせする振り方。
DBサーバはリストに対応するデータのサブセットだけもってればいい。
設計時になるべく一様になるキーを選ばないとリソースに偏りが出る。
7.レンジ
問い合わせ対象のデータによってレンジを求め、そのレンジに対応するサーバに問い合わせする振り方。
8.ハッシュ
問い合わせ対象からハッシュを求め、そのハッシュ値で選んだサーバに問い合わせする振り方。
DBサーバはハッシュに対応するデータのサブセットだけを持てばいい。
データのサブセットのみを持つと更新側にも同じルールの適用が必要。
分散KVS
NoSQL
格納データは単純さを求めた結果、PKと値という単純なデータ構造になってきた。
NoSQLの定義
1.キーと値
2.問い合わせにSQLのような重い解析を必要とする問い合わせ言語を必要としない
3.データは分散して配置され冗長性が高い
4.高負荷でもスループットが高い
相性がいいサービス
1.参照更新頻度が高い
2.データの更新参照に一時的に一貫性がなくてもいい
3.増え続ける大量のデータを格納したい
4.非正規化が容易
レプリケーションを利用した負荷分散
■スキーマ別レプリケーション
スキーマ別やテーブル別で分散する事ができる。
「Replicate_Do_DB」
my.cnf設定例
replicate-do-db = database1
replicate-do-db = database2
replicate-do-db = database1,database2
■テーブルごとの分散
「Replicate_Do_Table」
テーブルごとにSlaveサーバを分散する構成
※テーブルごとのレプリケーションとJOINは切っても切り離せない
物理的にJOINできない
my.cnf設定例
replicate-do-table=db_name.table_name
■ユーザーのIDをキーにしてテーブルの分割
ユーザーのIDを
キーにしてテーブルの分割を行い
レプリケーションで分散する
水平分割
■ストレージエンジンとレプリケーション
ストレージエンジンとレプリケーションを使った負荷軽減
MyISAMはトランザクションを使えない。
参照だけMyISAMを使う構成。
InnoDBも高速になってきたので、これはだんだんなくなった。
SELECTの発行回数が多い場合はSlaveサーバのストレージエンジンをMemoryエンジンにすることで速くなる。
alter table テーブル名 engine=memory;
■Masterサーバには不要なデータあるとき
MasterサーバのストレージエンジンをBLACKHOLEエンジンにすることで
MasterサーバのI/O負荷を軽減することが出来ます
BLACKHOLEエンジンはデータを保存・更新しないストレージエンジンになります
バイナリファイルのみ出力するので、Slaveに対してはデータが更新される。
http://blog.goo.ne.jp/sohgoh/e/44b19464bec097cb8063e42736639bcd
■Jdbcでのロード・バランシング
jdbc:mysql:loadbalance://host-1,host-2,...host-n/database?loadBalanceBlacklistTimeout=5000
jdbc:mysql:loadbalance://192.168.0.50:3306,192.168.0.50:3306/ensyu1
jdbc:mysql:loadbalance://192.168.0.50:3306,192.168.0.50:3306/ensyu1?loadBalanceBlacklistTimeout=5000
■はまりどころ
SLAVE START;
以降にreplicationされるのですが
これ以降のmasterへのupdateしか反映されません。
ですので、slave-master間の同一性を保つためには
replicationを開始する前に双方のデータベースの内容を同一にしておかなければなりません。
