LINEの技術 - オンラインデータリバランシング
急増するLINEインフラの課題と対応
http://tech.naver.jp/blog/?p=3041
上記のLINEのエンジニアのブログ内容が興味深い。
特に、DBのshardに関する部分の設計は、なるほどと思った。
見せてもらったことのあるシステムで、
DBを分割することを前提にテーブル設計してあるものを見たものはほとんど無かった。
いや、一つ見たことがあるけど、IDの番号からDBの番号算出して、
その番号DBにデータを書き込むというシステムだった。
単に余り(ID%10=DB-No)から番号出して、その番号のDBに書き込みだけ。
つまり、最初からDBを分割してからスタートアップしていた。
なので、最初からキャパとってるだけで、さらにそれ超えると作り直し。
設計したのはアホなのかと思う。
LINEのID管理は、
・IDから、ハッシュ値でグループ化
・ハッシュのグループにDB番号をマッピング
しているらしい。
マッピングも、現在のDB番号と、移行先のDB番号を用意しており、
システム的に無停止で増設などが出来る様に作っているらしい。
まぁ、そこの部分は自社開発の仕組みっぽいので、
参考になるのは、IDに関しては、
[ID-Hashグループ] -> [Hashグループ->Shard先/Shard移行先]
という感じで設計しておくのが良いよねって感じですかね。
Shardingに関してはこちらの解決策も併せて考えておきたい。
SPIDER for MySQL
http://spiderformysql.com/
