はてな伊藤直也さんの講演「はてな流大規模データ処理」の内容を以下にまとめ
例)はてなのデータ量
5178万レコード
1073万エントリー数･･･約2.5G
3134万ブックマーク数･･･約4G
4743万タグ･･･約3G
CPU負荷のスケーリングはカンタン
→ロードバランサー導入やサーバの追加で済む
I/O負荷の場合だとムズカシイ･･･
→単にサーバを増やしても根本的な解決にはならない
結局I/Oがボトルネックになってしまう
ポイントとして
いかにメモリ内で済ませるか！
メモリを増やす事でI/O負荷の軽減になる
全データ量＜物理メモリ量
これを満たしているならすべてをキャッシュ可能に
具体的な方法
・メモリ追加でI/O負荷軽減
→メモリを増設しI/Oウェイトを減らす事ができた
2Gぐらいまでのメモリなら今は安い
I/Oウェイトが下がるとCPU使用率が上がる
(本来させるべき仕事ができたと言う事。この方が理想的
CPU負荷が上がればサーバの増設等で対応ができる為)
・テーブル単位での分割
・リクエストパターンで分割
(ユーザのリクエストとgoogleボット君、画像APIではリクエストパターンが違う)
MySQLの運用
OSキャッシュを活かす
(Linuxは空いているメモリがあるとキャッシュに回す)
全データ量に気を配る
→(全データ量＜物理メモリ量を意識する)
インデックスを適切に
B-Treeインデックスを使用
インデックス無しの計算量･･･O(n)
インデックス有りの計算量･･･O(logn)
マスター・スレーブ構成
全体のほぼ9割が参照系なのでマスターの分散はあまり困らない
スレーブへの振り分けはLVSで
テーブル単位での分割(それぞれを別サーバへ)
→アプリケーション側の対応がちと大変
(JOINは使わずWHERE...IN...を利用）
でもやっぱ大量のデータを扱いたいって時は･･･
RDBMSでは限界
・テキスト走査
昔はgrepのやたら長い正規表現で対応
→これだとムリがあるので今はTRIEを使用
・転置インデックス作成
pros
cons
辞書はアルファベット順にソート済み
文書はID順にソート済み
バッチ処理について
1台では処理しきれない(へたすりゃ2･3日かかってしまう･･･)
MapReduceを使用(並列計算システムで大量のデータを扱うバッチ処理でつかわれている)
