連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
PHPからDBを使うときにはPEAR::DBをお使いの方もまだたくさんいらっしゃると思います。しかし、PEAR::DBのマニュアルにも「This package been superseded by MDB2 but is still maintained for bugs and security fixes」(このパッケージの代わりにMDB2の使用が推奨されますが、バグの修正、セキュリティフィックスは引き続き行われます。)と書かれているとおり、今後はPEAR::MDB2をお使いになることをお奨めいたします。 ということで、今回はPEAR::MDB2についてご紹介したいと思います。 PEAR::MDB2 マニュアル http://www.go-pear.org/manual/ja/package.database.mdb2.php MDB2についてはこちらをご覧下さい http://ww
ポイント ・高度なインデックスやジョインを利用し,最短経路でデータにアクセス ・メモリー不足を自律的に解消し,キャッシュのヒット率を高める ・インメモリーDBは全データをメモリーで処理し,高速化を図る 目的地に早く到着したいなら,最短の経路を最速で行けばよい。これはデータベース(DB)でも同様だ(図1)。インデックスなどを使ってデータへの最短経路を見つけ,メモリー・アクセスを増やして,最速でたどり着く。DBにはそんな技術が詰まっている。 図1●データベース高速化技術のポイント ビットマップ・インデックスなどを使い、データにたどり着く最短の道を選ぶ。また、できるだけメモリーにデータをキャッシュさせておくことで、アクセスのスピードを上げる、という二つのポイントがある [画像のクリックで拡大表示] 以下では,(1)データにたどり着く最短の道を選ぶ仕組みと,(2)アクセスのスピードを上げる仕組みの
シングルマスタの非同期レプリケーション機能では、マスタサーバーが1台に限定され、マスタからスレーブへの複製は非同期で行なわれるため遅延が生じ、短時間のスケールで見ると全スレーブとの同期が保証されない。しかし、その反面スレーブの台数を増加させていってもマスタサーバーの更新負荷は大きくならず、スケーラビリティを維持できるという利点がある。DeNAによる運用実績でも、マスタとスレーブ間の遅延は通常数秒程度以内に収まる。 このレプリケーションを利用する場合、アプリケーション側ではデータ更新時にはマスタサーバーへ接続し、データ参照のみを行なう場合はスレーブサーバーへ接続するように作成する必要がある。 Webや携帯電話向けサービスの場合、小さな規模で始めてユーザー規模、データ規模、ページビュー数を徐々に増加させていくことが多い。小さな規模のためDBの負荷分散が不要な場合でも、マスタサーバー1台、スレー
Railsで開発を行う際にDBは必須だろう。簡易的なものであればSQLiteで良いが、これまでの経験では大抵MySQLが利用されている。 DB管理にはphpMyAdminや、GUIのDB管理ツールを利用してきたが、Rails上で一括管理できるこちらが便利そうだ。 今回紹介するオープンソース・ソフトウェアはRailsMyAdmin、Rails上のDB管理ソフトウェアだ。 RailsMyAdminではRailsでのDB設定を利用するので設定も手間もなく簡単に利用できる。インストールはプラグインとして簡単にでき、environment.rbに設定を書き加えるだけでいい。 テーブルの一覧やデータの一覧表示、追加、編集はもちろん可能だ。また、created_at/updated_atといったRails特有のフィールドは値を入れられないのも便利だ。テーブル構造の変更はもちろん不可で、migration
「更新とJOINが多ければMySQL,シンプルなSELECT主体ならPostgreSQLが向いている。ストアド・プロシージャでシングル・コネクションならFirebirdは非常に速い」---6月23日に開催された「オープンソースカンファレンス2007.DB(OSC2007.DB)」で,各オープンソースDBのコミュニティのメンバーによる性能比較が披露され,従来の一般的なイメージとは異なる“意外な結果”が明らかにされた。 オープンソースカンファレンスは,オープンソース関連コミュニティが主催するイベントで,OSC2007.DBはデータベース関連のコミュニティが集まったイベントである。性能比較セッションを担当したのは,日本MySQLユーザ会の堤井泰志氏,日本PostgreSQLユーザ会の片岡裕生氏,Firebird日本ユーザー会の木村明治氏。「あくまでボランティアによる性能比較であって,最速,最新マ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く