clicklog

http://blog.hacklife.net/archives/51788873.html の各リンク先をざーっと読んでみた。
(わりと古い情報も多い。05-08 の情報。)

YouTube (Apr 07)

• キャッシュの有効利用
• IO の徹底的な並列化の追求
  • 大きなディスク少し vs 小さなディスクたくさん
• 独自レプリケーションシステム

livedoor

• 1ラック60台＠3kVA
• ディスクレス
• BGP4のTEには限界がある
• multimaster DB
• 「ここの負荷が上がるようならここを増強する」というポイントを意識しておくとスケールしやすい構成が組める
• データ転送 <<<< その他の処理 (レンダリングとか）
• 平均値はあてにならない (平均 0.2秒、MIN 0.1秒、MAX 240秒)
• チューニングはクライアントサイドとサーバサイドの両輪
• 10万件のデータのソート → ユーザが必要としてるのは先頭の10件

hatena

• LVS + keepalived
• CPU負荷のスケーリングは簡単、I/O負荷のスケーリングは難しい
• 現在のコモディティ：8GB～16GB (as of Nov 08)
• テキスト走査と転置インデックス

LiveJournal

• run in parallel ?
• common resource causing blocking
• partition datase (can't join but never mind)
• InnoDB: fast as hell
• MogileFS

flickr

• Unicode for all (really easy)
• UTF-8 is 7-bit transparent
• port exhaustion: 64,511 ports/120 sec port ~ 535 max concurrent connections per IP
• Always RAID10 (w/ battery backup for write caching or no caching at all)
• 15K drives >>> 10k drives

twitter

• ユーザごとにデータを重複して持たせることが、この問題に対する解法のひとつだ。
• データ更新のタイミングであらかじめ必要なデータを非同期に構築しておく (GREE)

eBay

• Scale Out, Not Up
• Virtualize Components
• WindowsNT/IIS
• J2EE
• Impact of Latency
• Partition Everything, Async Everywhere, Automate Everything, Remember Everything Fails

del.icio.us

• SQL でスケーリングするのではなく、データを複数マシンに分散させる方法を考慮すべき

Pathtraq

• 32GB-64GB per server is today's sweet spot (memory)
• search in compression form

Gree

• 複数のサービスでの機能連携は前提にしておいたほうがよかったなぁ
• slow-logをみてEXPLAINしてみたり
• 各ウェブサーバでちょっとずつソースコードが違う。衝撃。(笑)

mixi

• 水平分割(機能)と垂直分割(ユーザID)
• Partition map for level 2: Manager based and Algorithm based
• マシンのメモリが4GBあるにも関わらず，割当を3GBとしているのは，これ以上の割当を行うとメモリがswapする恐れがあるためです。

っていうか、MySQL ばっかだな。