ふぁぼったーの負荷分散の計画をあれこれ考えてみた。
今日一日調べたこととかまとめてみる。
問題点
- 次回リリースの新機能はDB select負荷がかなり掛かるはずである。
- 現状でもデータLOADによる負荷が10に達し、selectにスロークエリ、接続エラーが出ている。DBの負荷分散が急務である。
参考: Load Average
参考: Slow Query
- あと、STATUSテーブルが2GBに達しようとしているので、デフォルトのサイズ制限4GBが見えてきた。再定義できるけど。
垂直分割対応案
日本語版DBと英語版DBのデータベースとクローラを別ホストに格納する
- 現状、favotterとfavotter_enはほぼ同規模のDBとなっている。
- ただし、参照は圧倒的にfavotterが多い。
- favotter_enのクローラを止めたら、スロークエリが激減した事がある。
- クロール負荷とINSERT負荷はかなり減るだろう。論理的にも簡単。
- しかし参照負荷に差ががあるのが気がかり。
レプリケーションする
- Webが参照するスレーブDBから、クローラの実行負荷を分離する事が出来る。
- しかし、INSERT処理はマスタにもスレーブにも等しく走るので、このDBへの挿入負荷をスレーブDBから分離する事はできない。
- 問題はINSERT時のテーブルロックだと思われるので、クローラ負荷が分離したところで効果はやや疑問。
水平分割対応案
MERGEテーブルを利用する
結論
こうして考えると、水平分割はふぁぼったー検索がTritonnに依存している関係上、一筋縄ではいかない。
ふぁぼったー検索をTritonn以外の方法(例えばGroonga単体)で実装すれば、ふぁぼったーはTritonn(=MySQL5.0.45)の呪縛から解き放たれ、MySQL5.1にアップグレードしモダンなパーティショニングを使う事ができる(MERGEテーブルは使いたくない)。
しかし、ふぁぼったー検索は、通常の全文検索だけでなく
- 動的に増加するfav数によるフィルタリング
- ユーザーによるしぼりこみ
- ふぁぼりユーザー(fav_by)によるしぼりこみ
- ユーザーのprotect状態変更への追従
- 発言削除への追従
と、DBから分離して管理するには面倒な要件が盛りだくさんなので、片手間で独自実装するのは現実的とは思えない。つまり、Groonga MySQLストレージを待ちたい。
一方垂直分割に関しては、レプリケーションとDB分離、どちらがメリットがあるかすぐには分からないが、どちらも仕組みはとても簡単なので、どちらとも評価して決めればよい。総論として、ふぁぼったーDB負荷分散戦略としては、
「Groonga MySQLストレージエンジンを待望つつ、レプリケーションまたは日本・英語DBの分離を行う」
で決まりかと思われる。と結論が出たところで寝ます。おやすみなさい。
