- 2010/04/21 20:08:15nosql architecture twitter hadoop +
Twitterを支えるアーキテクチャの本当のポイント
萩原正義氏が語る、Twitterを支えるアーキテクチャで見るべき本当のポイント。先に以下の記事をどうぞ。
なぜTwitterは低遅延のままスケールできたのか
●秒間120万つぶやきを処理、Twitterシステムの“今”
http://www.atmarkit.co.jp/news/201004/19/twitter.html
萩原正義氏のプロフィール
▼続きを読む(残り1行)
by knsmr7 fav 1673 view
まとめ
メニューを開く-
twitterのsocial graphの実装は単純な対照表なのでグラフのような複雑なデータ構造を辿ることになる1階述語特有の操作になる。高階述語のモデル化とき、このあたりはよく考えました。他にもtowitterのデータモデル設計では古典的な手法がいろいろと使われてます。 -
Hadoopにしてもno SQLにしてもユースケースを識別し、それを集合演算を始めとするデータ操作に分解して、それぞれの操作に対して最適化を考えるという流れは変わらない。その最適化の中にデータモデルの選択や物理配置の決定が含まれます。twitterの基本設計もこの原則にそっている
-
twitterの設計で最も優れているのはスケーラビリティというより、タイムラインの範囲でクエリーを制限したりしたスコープの限定にあります。その結果アーキテクチャが単純化。スコープの定義はアーキテクチャを決める上で最初に行うべき重要な意思決定です。140文字というのもスコープ定義。
-
tweetした文字数が140文字ぎりぎりだと http://twishort.com を使えというアドバイスが来ました。140文字を超えることが書けるようです。すばらしい。
-
最後に面白いこと。twitterはエンタープライズには進出しないと言ってました。エンジニアの意見だから、本当かどうかわかりませんが。
-
ビジネスプロセスの意思決定は活動の時間推移の追跡であって、実時間の観測と履歴分析結果に基づくことが中心。前者が時間的局所性を持つクエリーで、一貫性の解決は遅延可能。後者がバッチ処理上のマイニング。だから、世の中はその方向に進んでいる。
-
時間推移の追跡に関してtwitterが基本設計の事例を示している。だから、僕はそこのエンジニアと話をしたいと思った。単純な興味からだけではありません。
-
Content from Twitter
コメント