
自分なりにざっくりと内容をまとめると、以下でしょうか。
1.ユーザー・情報が膨大となった時、単にスケールするだけはでなく、仕組み自体を変えないといけない
2.その時考えるべきは、キャッシュ、データ構造、アルゴリズムの3つ
せっかくなので簡単にこの2つについて書きます。
1.ユーザー・情報が膨大となった時、単にスケールするだけはでなく、仕組み自体を変えないといけない
データベースについての話が一番おもしろかったのでここで取り上げます。
ご存知の通りデータベースには様々な情報を格納することができますが、様々な制限から無限に情報を格納できるわけではなくて、必ず限界があります。扱う情報が膨大となり、その限界を超えてしまうことは容易に想像できます。その時どうするかという話です。
現状よくやられる対応として、情報を分割して複数のデータベースに分けて格納するというものがあります。例えば 100 しか入らないデータベースに 10,000 を入れたければ、情報を 100 ずつ 100 個に分割して、100 のデータベースに分けて格納する感じです。当然分割には規則があり、欲しい情報がどのデータベースにあるかは分かるようになっています。
発想としてはわりと単純ですが、データベースを複数台用意するコスト、複数台から目的の情報を持ったデータベースを選択するコストがわりと小さいので、現状とても現実的な方法と言えます。
# しかしながらやっぱりそれ面倒くさいよってことで、次世代のデータストアとしてその辺よしなにやってくれる Cassandra などが注目されているようです。(補足1)
# しかしながらやっぱりそれ面倒くさいよってことで、次世代のデータストアとしてその辺よしなにやってくれる Cassandra などが注目されているようです。(補足1)
2.その時考えるべきは、キャッシュ、データ構造、アルゴリズムの3つ
キャッシュ、データ構造、アルゴリズムと書きましたが、結局のところ、データへのアクセス速度をできる限り上げて、計算量をできる限り減らそうということです。
キャッシュが重要というのは、メモリからの読み出し速度がハードディスクと比べて 10 万から 100 万倍速いためです。ほしい情報ができるだけメモリから読み出せれば、それだけでかなり高速化できるということです。僕も昔これで 3h の処理が ~10s になりました。使いそうな情報はできるだけメモリに乗せちゃいましょう。
データ構造とアルゴリズムですが、n^2 のオーダーには気をつけましょう、インデックス張りましょうというよくある話です。基本的な事項ですが無視すると大変なことになるのでとても重要ですね。
最後に
以上。
# あーなんかすげー長くなってしまった。。
補足1:
Cassandra実践入門―Twitter,Facebookが採用するNoSQLシステム
TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由
Twitterの大規模システム運用技術、あるいはクジラの腹の中(後編)
Facebookが大規模スケーラビリティへの挑戦で学んだこと(後編)
No comments :
Post a Comment