mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
mixiのシステム、海を渡る？ MySQLの事例に
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 2004年2月にサービスを開始、わずか3年3カ月で1000万人以上のユーザを獲得したmixi。日本を代表するソーシャルネットワーキングサービス（SNS）のシステムがMySQLの事例記事としてMySQL ABのサイトで紹介されている。 MySQL ABでは、MySQLのスケーラビリティを実証すべく「The 12 Days of Scale-Out」と呼ばれるキャンペーンを展開していた。mixiの事例はこの「番外編」のような形でDay Twelveの後に紹介されている。 MySQL ABによる事例記事の中ではmixiのシステム構成にも触れられている。同社はMySQLのマルチ・マスター・システムとパーティショニング機能を使ってスケーラビリティ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
