Twitterを支えるアーキテクチャの本当のポイント

Masayoshi Hagiwara @masayh

twitterのsocial graphの実装は単純な対照表なのでグラフのような複雑なデータ構造を辿ることになる1階述語特有の操作になる。高階述語のモデル化とき、このあたりはよく考えました。他にもtowitterのデータモデル設計では古典的な手法がいろいろと使われてます。

Masayoshi Hagiwara @masayh

Hadoopにしてもno SQLにしてもユースケースを識別し、それを集合演算を始めとするデータ操作に分解して、それぞれの操作に対して最適化を考えるという流れは変わらない。その最適化の中にデータモデルの選択や物理配置の決定が含まれます。twitterの基本設計もこの原則にそっている

Masayoshi Hagiwara @masayh

twitterの設計で最も優れているのはスケーラビリティというより、タイムラインの範囲でクエリーを制限したりしたスコープの限定にあります。その結果アーキテクチャが単純化。スコープの定義はアーキテクチャを決める上で最初に行うべき重要な意思決定です。140文字というのもスコープ定義。

Masayoshi Hagiwara @masayh

tweetした文字数が140文字ぎりぎりだと http://twishort.com を使えというアドバイスが来ました。140文字を超えることが書けるようです。すばらしい。

Masayoshi Hagiwara @masayh

最後に面白いこと。twitterはエンタープライズには進出しないと言ってました。エンジニアの意見だから、本当かどうかわかりませんが。

Masayoshi Hagiwara @masayh

こういうボトルネックはだめです。 @frsyuki プライマリキーを連番で生成するサーバは専用に用意する

Masayoshi Hagiwara @masayh

@frsyuki idの生成は最もボトルネックになる部分、これ常識です。しかも連番だからトランザクション実行するでしょう。やってみないとわからないけれど、設計段階でいいアーキテクチャではないと思います。

Masayoshi Hagiwara @masayh

この特性はもっと応用範囲は広いです。エンタープライズの基本要求にしてもいい。現在のno SQLを設計している人はドメインモデルの実要求についてもう少し意識したほうがいい。汎用性がかえって有効性を損なう。@frsyuki 時間的局所性は、オンラインなサービスでは一般に効くだろう。

Masayoshi Hagiwara @masayh

ビジネスプロセスの意思決定は活動の時間推移の追跡であって、実時間の観測と履歴分析結果に基づくことが中心。前者が時間的局所性を持つクエリーで、一貫性の解決は遅延可能。後者がバッチ処理上のマイニング。だから、世の中はその方向に進んでいる。

Masayoshi Hagiwara @masayh

時間推移の追跡に関してtwitterが基本設計の事例を示している。だから、僕はそこのエンジニアと話をしたいと思った。単純な興味からだけではありません。