MySQL負荷分散のまとめ

はてぶで人気エントリーになっていた、


http://kokoromo.jugem.cc/?eid=195
[MySQL:1台しかない環境で負荷分散]


これは負荷分散=スケールアウトというよりは一台でスケールアップしてしのぐ手段を書いてい。
だから負荷分散という言葉は必ずしも正しくないのだが、一つのテーブルへの付加集中を分散させるという事なのだろう。


そこで何パターンかあるMySQLの負荷分散を簡単にまとめてみる。


1. 富豪的分散
商用のクラスター製品を使う。
最近はMySQL専門のクラスター製品が出てきている。
http://www.continuent.jp/pro.html
なんかは良いかなと思う。


長所:
プログラム側ではクラスタ状態を何の意識もせず、一つのターゲットに対してクエリーを発行すれば良い。
ターゲットが複数台ある事は意識する事は無い。
不具合があるノードに生じた場合、他のノード達が自動フェイルオーバーしてくれる。
なので、どのノードも好き勝手に停止してメンテナンスさせられる。
短所:
お金がかかる。
特にこういった製品は、ノード数が増えれば増える程費用がかかって行く。


2. 経済的に優しい分散
MySQL標準のレプリケーション機能を使う。
マスターとスレーブが出来て、マスターに発行された挿入・更新系のデータはスレーブにも即時に反映される。
よって、挿入、更新系のクエリーはマスータに対して発行し、検索系のクエリーは複数台にレプリケーションされたスレーブ側に対して行う。
この事によって負荷を分散させる。
スレーブの方はtmpfs(仮想メモリディスク)なんかを使ってそこにレプリケーションされるテーブルを配置しておけば、より一層、検索の効率が向上する。つまり早くなる。


長所:
マシンさえ複数台あれば無料でシステムを構築できる。
標準のレプリケーション機能なので、ネット上に情報が多い。


短所:
プログラム側で更新系・挿入系クエリーの場合と検索系の場合でアクセスするDBサーバを変えてやらなければならない。その分ロジックが複雑になるか、または、それを隠蔽するフレームワークが必要。
マスターは結局は負荷分散されない。マスターはクリティカルのまま。
よって、マスタ−に被害が生じた場合は復旧は大変。


3. 自宅サーバ組の負荷分散
上記冒頭URLに上げた、一台でスケールアップをする方法。
あるテーブルに対する複製テーブルをHEAPテーブルとしてメモリ上に作る。
挿入系・更新系の場合は元の物理ディスク上のテーブルとHEAPテーブル両方に対して行う。
つまり二回発行する。
検索系のクエリーの場合はHEAPテーブルに対して行う(スピードが早くなるから)。


長所:
プログラムで二回更新系クエリーを発行してやりさえすれば簡単に運用できる。
マシンが一台でよい。
つまり全く費用をかけずに一台のDBサーバの性能を向上できる。


短所:
結局は一台なので、マシンの物理ディスクの損傷他の障害でDBサーバはストップする。
つまり冗長性はない。
一台のマシンでとれるHEAPテーブルの大きさや数はすぐに限界がくる。


自宅サーバ派の人は3番のやり方をやってみると面白いと思う。
どれくらい性能が向上するのか。
私もやっていないのでわからない。
でも面白い考え方だと思う。