2006-03-08
■[プログラミング]MySQL負荷分散のまとめ
はてぶで人気エントリーになっていた、
http://kokoromo.jugem.cc/?eid=195
これは負荷分散＝スケールアウトというよりは一台でスケールアップしてしのぐ手段を書いてい。
だから負荷分散という言葉は必ずしも正しくないのだが、一つのテーブルへの付加集中を分散させるという事なのだろう。
そこで何パターンかあるMySQLの負荷分散を簡単にまとめてみる。
1. 富豪的分散
商用のクラスター製品を使う。
http://www.continuent.jp/pro.html
なんかは良いかなと思う。
長所：
プログラム側ではクラスタ状態を何の意識もせず、一つのターゲットに対してクエリーを発行すれば良い。
ターゲットが複数台ある事は意識する事は無い。
不具合があるノードに生じた場合、他のノード達が自動フェイルオーバーしてくれる。
なので、どのノードも好き勝手に停止してメンテナンスさせられる。
短所：
お金がかかる。
特にこういった製品は、ノード数が増えれば増える程費用がかかって行く。
2. 経済的に優しい分散
マスターとスレーブが出来て、マスターに発行された挿入・更新系のデータはスレーブにも即時に反映される。
よって、挿入、更新系のクエリーはマスータに対して発行し、検索系のクエリーは複数台にレプリケーションされたスレーブ側に対して行う。
この事によって負荷を分散させる。
スレーブの方はtmpfs（仮想メモリディスク）なんかを使ってそこにレプリケーションされるテーブルを配置しておけば、より一層、検索の効率が向上する。つまり早くなる。
長所：
短所：
プログラム側で更新系・挿入系クエリーの場合と検索系の場合でアクセスするDBサーバを変えてやらなければならない。その分ロジックが複雑になるか、または、それを隠蔽するフレームワークが必要。
マスターは結局は負荷分散されない。マスターはクリティカルのまま。
よって、マスタ−に被害が生じた場合は復旧は大変。
3. 自宅サーバ組の負荷分散
上記冒頭URLに上げた、一台でスケールアップをする方法。
あるテーブルに対する複製テーブルをHEAPテーブルとしてメモリ上に作る。
挿入系・更新系の場合は元の物理ディスク上のテーブルとHEAPテーブル両方に対して行う。
つまり二回発行する。
検索系のクエリーの場合はHEAPテーブルに対して行う（スピードが早くなるから）。
長所：
プログラムで二回更新系クエリーを発行してやりさえすれば簡単に運用できる。
マシンが一台でよい。
つまり全く費用をかけずに一台のDBサーバの性能を向上できる。
短所：
結局は一台なので、マシンの物理ディスクの損傷他の障害でDBサーバはストップする。
つまり冗長性はない。
一台のマシンでとれるHEAPテーブルの大きさや数はすぐに限界がくる。
自宅サーバ派の人は3番のやり方をやってみると面白いと思う。
どれくらい性能が向上するのか。
私もやっていないのでわからない。
でも面白い考え方だと思う。
Permalink | コメント(1049) | トラックバック(0) | 10:12 
- 3 http://b.hatena.ne.jp/entry/http://kokoromo.jugem.cc/?eid=195
- 2 http://d.hatena.ne.jp/keyword/iLife
- 1 http://ask.jp/blog.asp?o=0&qsrc=96&q=免許更新 江東&hq=&btnBlg.x=83&btnBlg.y=15
- 1 http://blog.goo.ne.jp/search/search.php?status=select&tg=all&st=time&dc=10&dp=all&da=all&ts=all&MT=コールドプレイ 先行&st=time
- 1 http://d.hatena.ne.jp/keyword/水戸偕楽園
- 1 http://d.hatena.ne.jp/keyword/iLife?kid=86817
- 1 http://d.hatena.ne.jp/keyworddiary/MySQL?date=20060308
- 1 http://d.hatena.ne.jp/keywordmobile/自宅サーバ?kid=21442
- 1 http://d.hatena.ne.jp/keywordmobile/長所
- 1 http://mixi.jp/view_diary.pl?id=85873587&owner_id=416933
