BP Study #59 MySQL を分割する話 [Python]
http://connpass.com/event/702/
２部の、ソーシャルゲームで MySQL を分割する話について忘れないようにメモしておく
- 対応ができるまでユーザーの入場を制限
（その間に３週間で準備）
- memcached は、台数増やして、Django の設定でスケールできた
- TokyoTyrant をやめて、MySQL を複数並べてキーにより振り分けて記録
（以下、メインのMySQLに入っているデータの分割）
- キーを、DB 毎の auto increment されてる値から User ID や uuid を作って使う
- 外部キー制約を外す。そのためのモデル定義も修正
- 外部キー制約経由でアクセスしていた部分の書き換え
- Django の db router を使って振り分ける
https://docs.djangoproject.com/en/dev/topics/db/multi-db/
- MySQL 16分割→縮退、増強する場合も 1/2,1/4,2倍,4倍としやすいように
- mysqldump して、スクリプトで分割するDB毎の SQL 作る
- RDS のSnapShot とる ＆ リハーサルして時間を計測する
（以下、それ以後の開発について）
- South に手動でマイグレーションスクリプト書いて、DB 毎に存在するテーブルと
そうでないマスター系のテーブルの作成を制御する
聞いてる人は、なんで TokyoTyrant なの？なんで AWS なの？なんで RDSなの？
と思ったんだろうけど、それを検討してる余裕もないのはよくわかる。
なにしろ、インフラの金銭的な面はある程度余裕があるので、とにかく速く解決したい。
きっと今なら EC2 のすごいの使ってみようとかなるんだろうな。
http://d.hatena.ne.jp/rx7/20120727/p1
印象的だったのは、今はほとんど Foreign Key 制約を付けていないとのこと。
速度的に、そのほうが有利ということと MySQL を分割することを考えたらそのほうがいい、ということらしい。
ほとんど制約をつけないという話は、随分前に「はてな」でそうしてるという話は聞いたが、僕らは、とにかく作るのに時間がかけられなくてプログラムの ロジックで制約を担保する余裕がなくて、できるだけ RDBMS の制約をつけようというアプローチだった。
制約を付けないことで困ることはあんまりない、とのこと。立派だ。
ソーシャルアプリの高負荷の環境で Django 使ってると、普通の Model アクセスしない（できない）ので、他にいくと結構恥ずかしいのだが、上のなかで、主キーは Django の autoincrement な ID じゃなくて、ユニークに定義されるものを設定するというのは、他のジャンルでも共通して役に立つのかな、と思った
Djago では
user_key = IntegerField(pk=True)
と pk=True と書いておくと、user_key が主キーとして使われる。（んで、id というカラムが作られない）
でも、意味合い的なキーと、autoincrement な ID と、別々に持てた方がうれしい場合もあるので（user_key が変わっちゃうとか）微妙か
２部の、ソーシャルゲームで MySQL を分割する話について忘れないようにメモしておく
- 対応ができるまでユーザーの入場を制限
（その間に３週間で準備）
- memcached は、台数増やして、Django の設定でスケールできた
- TokyoTyrant をやめて、MySQL を複数並べてキーにより振り分けて記録
（以下、メインのMySQLに入っているデータの分割）
- キーを、DB 毎の auto increment されてる値から User ID や uuid を作って使う
- 外部キー制約を外す。そのためのモデル定義も修正
- 外部キー制約経由でアクセスしていた部分の書き換え
- Django の db router を使って振り分ける
https://docs.djangoproject.com/en/dev/topics/db/multi-db/
- MySQL 16分割→縮退、増強する場合も 1/2,1/4,2倍,4倍としやすいように
- mysqldump して、スクリプトで分割するDB毎の SQL 作る
- RDS のSnapShot とる ＆ リハーサルして時間を計測する
（以下、それ以後の開発について）
- South に手動でマイグレーションスクリプト書いて、DB 毎に存在するテーブルと
そうでないマスター系のテーブルの作成を制御する
聞いてる人は、なんで TokyoTyrant なの？なんで AWS なの？なんで RDSなの？
と思ったんだろうけど、それを検討してる余裕もないのはよくわかる。
なにしろ、インフラの金銭的な面はある程度余裕があるので、とにかく速く解決したい。
きっと今なら EC2 のすごいの使ってみようとかなるんだろうな。
http://d.hatena.ne.jp/rx7/20120727/p1
印象的だったのは、今はほとんど Foreign Key 制約を付けていないとのこと。
速度的に、そのほうが有利ということと MySQL を分割することを考えたらそのほうがいい、ということらしい。
ほとんど制約をつけないという話は、随分前に「はてな」でそうしてるという話は聞いたが、僕らは、とにかく作るのに時間がかけられなくてプログラムの ロジックで制約を担保する余裕がなくて、できるだけ RDBMS の制約をつけようというアプローチだった。
制約を付けないことで困ることはあんまりない、とのこと。立派だ。
ソーシャルアプリの高負荷の環境で Django 使ってると、普通の Model アクセスしない（できない）ので、他にいくと結構恥ずかしいのだが、上のなかで、主キーは Django の autoincrement な ID じゃなくて、ユニークに定義されるものを設定するというのは、他のジャンルでも共通して役に立つのかな、と思った
Djago では
user_key = IntegerField(pk=True)
と pk=True と書いておくと、user_key が主キーとして使われる。（んで、id というカラムが作られない）
でも、意味合い的なキーと、autoincrement な ID と、別々に持てた方がうれしい場合もあるので（user_key が変わっちゃうとか）微妙か
コメント 0