非常に有名なソーシャルアプリケーションであるTwitter(サイト)の基調を成すアーキテクチャーが、近ごろ議論の対象となっている。Twitterはダウンタイムのインスタンス(source)があり、チームが問題の対処に乗り出すにつれて(source)、人気のある機能がいくつか登場した(source)。Twitterが前進しようとしている現状を観察することで、どんなことが分かるのか?
Om Malik氏(source)およびDare Obasanjo氏(ブログ・英語)をはじめとする人びとが、問題へと導いたTwitterのベースを成すアーキテクチャーについて深く考えた。さらに最近では、 Robert Scoble氏がTwitteのEvan Williams氏およびBiz Stone氏にインタビューし(source)、アプリケーションおよび企業の今後について尋ねた。そのインタビューの全ストリーミングビデオは、qik(source)で見ることができる。
インタビューで、Williams氏およびStone氏がTwitterのデータアーキテクチャに関する大問題に答えた。それは、Twitter はユーザメッセージへSingle Instance Storage (SIS)のアプローチタイプ(ブログ・英語)を使用しているのか、というものであった。インタビュー開始から13分のあたりで、Williams氏はメッセージストレージおよびユーザタイムラインリトリーブについて語った。
Om Malik氏(source)およびDare Obasanjo氏(ブログ・英語)をはじめとする人びとが、問題へと導いたTwitterのベースを成すアーキテクチャーについて深く考えた。さらに最近では、 Robert Scoble氏がTwitteのEvan Williams氏およびBiz Stone氏にインタビューし(source)、アプリケーションおよび企業の今後について尋ねた。そのインタビューの全ストリーミングビデオは、qik(source)で見ることができる。
インタビューで、Williams氏およびStone氏がTwitterのデータアーキテクチャに関する大問題に答えた。それは、Twitter はユーザメッセージへSingle Instance Storage (SIS)のアプローチタイプ(ブログ・英語)を使用しているのか、というものであった。インタビュー開始から13分のあたりで、Williams氏はメッセージストレージおよびユーザタイムラインリトリーブについて語った。
全ユーザフォロワーのメッセージをコピーしたりしませんが、実際はもっと効率的かもしれません。現在データベースに入り、タイムラインが必要なときは、 データベースからタイムラインを構築し、毎回ではないけれども、メモリー内にキャッシュします。書き込みが非常に多いので、単にキャッシュをアップデートするためにデータベースを多く使用します。ですから、キャッシュには大量の(メッセージの)コピーがあります。でも、ディスクには1つのみです。われわれのアーキテクチャーについては、今後むしろ書き込みを多数おこなうことに近いかもしれません。そうすれば読み出しがずっと高速になるからです。SISメッセージアーキテクチャーから脱皮する可能性が、高容量のサイトやアプリケーションですでに人気を博しているData Shardingのようなデータテクニック(source)を使用するという道を切り開く。Randy Shoup氏は、shardingを使用し、ある程度の高いスケーラビリティーを目的としてeBayがシステムを設計した方法について語った(参考記事・英語)。
定義からしてデータはステートフルなので、データベース層で最も難しい問題は発生します。ここで、はじめのアクセスパスに対して並行にデータを分割します。たとえば、現在ユーザデータは20ホスト以上に分割されていて、各ホストはユーザの20分の1を含んでいます。ユーザ数が増加するにつれ、またわれわれが格納する各ユーザのデータが増大するにしたがって、ホストを追加し、さらにユーザを再分割します。繰り返しになりますが、アイテム、注文、アカウントごとに同じアプローチをとっています。さまざまなユースケースがデータの区画化のための、さまざまなスキーマを使用しています。Bogdan Nicolau氏は、データベースshardingの概要(source)について書いた。Bogdan氏は、アプリケーションのためにデータを分割する場所とその方法について決定する方法について議論した。決定する際の重要点は、
言わんとしていることは、たとえ選択したロジックがテーブルを分割しても、0ジョインが必要で、命令や複数のテーブルの分割を必要とする可能性のある制限条項を常に念頭に置いておかなければなりません。Bogdan氏は、shardingすることのアプリケーションサイド(source)に移った。複数のコードサンプルを提供して、サンプル問題とうまくやっていくことの他に、Bogdan氏は作業する理由を以下のように述べた。
見て分かるように、マッピングテーブルにデータを追加する必要があるので、書き込みの部分に重点がおかれています。読み出しの場合、関連するデータアルゴリズムの分割はもはや問題ではありません。
見て分かるように、マッピングテーブルにデータを追加する必要があるので、書き込みの部分に重点がおかれています。読み出しの場合、関連するデータアルゴリズムの分割はもはや問題ではありません。
InfoQには、パフォーマンスや拡張可能性に関するリソースがある。ここで参照できる(参考記事リンク)。
原文はこちらです：http://www.infoq.com/news/2008/06/twitter-and-sharding