大規模SNSのボトルネックとソリューション
フックメソッドの追加 当然ですが、データ更新時にフックをかけるためには、データの更新パスを可能な限り絞り込んでおく*（ソースコード中に同じような処理が散らばらないようにする）必要があります。GREEでは、テーブルごとにデータベースインタフェースが定義されていて、更新処理が行われるのはINSERT/UPDATE/DELETEを行う3種類のSQL文だけなので、「あるテーブルが更新されるパス」は簡単に絞り込めます*。 ですので、これらのSQL文を呼んでいる個所に、次のようなコードを追加することで安全にフックをかけることができます。 とはいえ、データベースアクセスレイヤーにフック処理を追加するのは設計上美しくないですし、実際問題このようなフック機構を実装しようとすれば、 フックメソッドに必要な情報を渡すことができない コンテキストによっては無用なフックをかけてしまう といった問題が出てくることがあ
大規模SNS実現のためのGREEのアプローチ
ボトルネックはデータアクセス Webアプリケーションでは、とにかくレスポンスタイムが重要になります。レスポンスタイムはユーザーの使い勝手に直結しますし、あまりにレスポンスが悪いとユーザーはページのリロードを試みます。つまり、トラフィックがさらに増えるわけで、サチュレーション*が起こってしまうのです。これを避けるためには、基本的なレスポンスタイムを低く抑える必要があります。 そのためWebアプリケーション開発者の間では、データアクセスのスケーラビリティ確保がよく話題に上ります。大規模サイトに使われるようなWebアプリケーションであれば、ストレージへのアクセス手段としてRDBMSが使われており、特にOSSのRDBMSであるMySQLやPostgreSQLのチューニング方法がよく議論されます。 しかし、結局のところ、「インデックスを正しく利用する、パラメータを正しく設定する」などという基本的な対
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
