ぶろぐ

日記です

RDBの負荷対策について聞いてみた


iDCNOCで働いている友人に聞いてみた
勝手に要約しているので、オレフィルターで話がずれているかも(笑)

会話

オレMySQLのマスター/スレーブ方法のレプリケーションって、負荷対策の目的ではなくて、可用性高める目的で使うのが普通みたいだな…。参照系の負荷分散はできるかもしれないけど、更新系の処理は、マスターにしか投げれないから」
オレmixiとか、ログイン処理に限っての話かもしれないけどMySQL一台+レプリケーションで一秒間に10000の更新クエリをさばいているらしいぞ…いちょ、tokyo tyrantとかゆー高速KVSをキャッシュとしてワンクッションはさんでいるらしいけど….RDBMSって技術的に見てそんなにスケールアウト難しいの?」
相手「更新系の負荷分散はクラスタリング組むしかないかもしれないなー。DBは基本的に参照系の負荷分散が主なイメージだ。でも、方法がないわけではない.

監視している環境見たが、更新系の負荷分散はされていなかった.50ずつ、50ずつでテーブルを分けておいているんだはず」
オレ「50ずつ50ずつって…
アプリケーションサーバーが、マスターのDBを指定して、更新系の処理は投げているってこと?
(更新系はサーバー層ではなにもしない、プログラマが判断)」
相手「更新系をAPサーバーが指定して投げてる。」
オレ「(あっているってことかな?テーブルの結合とかどうやるんだろ?やっぱ有力なのはクラスタか…)そっか、テーブル分ければいけるね.てかパーティションっていう技術もあるのか!じゃあ、全然負荷対策できるな.KVSとかがやたらと注目されていから、RDBMSって大規模の更新系に限界があるのかなーとかふと思ってしまったw」
相手Oracleがいるのにそんなイメージをもっちゃいかんぞwww」

メモ

フェールオーバーとか細かい話は割愛(分からないし)
調べてみると、MySQL Proxyとかゆーのもあるみたいで.
アプリケーション側で使うDBを分けるとか、そういうのもありなんだな.
大規模環境のログをみてみたい!
実際にvmwareでサーバーポンポン建ててレプリケーション組んで遊んでみよー
と思った一日でした.
なんつーか、、話きいただけじゃわかんない.自分でやらなきゃわかんないなー…。構成図欲しいな(笑)