Twitterのテーブルは3つで構成されているかも（DB入門編）

Posted on 2月, 14 at 12:23 am

何気なく、風呂に入りながら「Twitterっていくつのテーブルで構成されているんだろう」と思ってしまって、DBの構造を推測してみた。仕事ではSalesforceのテーブル管理をしたことがあるが、ヤツはとんでもないテーブル数を持っていて、どこに何が格納されているのかさっぱり予測できない。当然カンペキに正規化されているんだろうけれども、あれだけ複雑なアプリケーションであるのと、やっぱりクライアントごとにしっかりデータを分けなければならないというポリシーがあるはずだから（営業データだからね・・）、基本的にはテーブル単位、あるいはDB単位で分けているんだと思う。

で、Twitter。「無料のつぶやきサービス」というサービスで、先のSalesforceとは求められるSLAがまったく異なる。個人単位でデータをエクスポート／インポートすることもない。爆発的に増加するユーザや爆発的に発生するつぶやきに、いかにスケーラブルに対応するかが、このサービスのポイント。それらのポイントをクリアするためには、どのようなテーブル構成が求められるのだろうか。元DBエンジニアの端くれとして、風呂の中で考えてみたのでメモしておきます。現役のエンジニアさんにとってはレベルの低い話なのでスルーしていただければ。

まず基本要件が、大きく３つ。

自分のつぶやきと自分のフォローしているアカウントのつぶやきをタイムラインで抽出できる

自分がフォローしているアカウントの一覧を抽出できる

自分をフォローしているアカウントの一覧を抽出できる

これがTwitterの基本機能（のはず）。そうすると、Salesforce的な設計であれば、

①アカウント一覧テーブル（全ユーザのアカウントを管理。アカウントID、パスワード、アイコン、各種プロファイル）

②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID）

③フォロー一覧テーブル（登録日付、アカウントID）

④被フォロー一覧テーブル（登録日付、アカウントID）

となるが、この設計だと①を除いた②③④は、アカウントごとにテーブルを用意する必要がある。ユーザーには利用頻度に違いがあるので、一度アカウントを作ったけれどもまったく利用していないユーザーに対してもこれらのテーブルを用意しておかなければならない。論理的に確保しておくだけなのでユーザーが少ないうちは気にする必要はないかもしれないが、その数が数千、数万を超えるようだと無視できないサイズになる。DBの中ではテーブルを作成すると、レコードが入っていようがいまいが、一定の領域を確保してしまうからだ（表領域と言います）。

ちなみに、下はTwitterのアカウント登録数推移。毎日20万～30万人のユーザーが新規登録している。恐ろしい規模だ。この規模で上のような設計をしていたら、ストレージがいくらあっても足りない。

ではそれぞれの共有できるテーブルにしていくには。①は共通のテーブルだからいいとして、②は全ユーザーで共有できそうだ。カラムの構成を

②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID）

から

②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID、アカウントID）

とする。こうすれば②も共有できる。自分だけのつぶやき一覧は、SQLで条件指定（where ユーザーID＝xxx order by 日付）

で抽出することができる。何億ユーザになっても、テーブルは１つで済む。

しかし、③と④がまだユーザー単位に必要だ。というわけで次に③と④をやっつけていく。

結論から言うと、③と④は合体して、１つのテーブルで管理できる。難しく考える必要はなくて、

③フォロー一覧テーブル（登録日付、アカウントID、）

④被フォロー一覧テーブル（登録日付、アカウントID）

から、

③＋④フォロー関係一覧テーブル（登録日付、フォロー元ID、フォロー先ID）

するだけ。錆付いた頭では、頭の中だけで考えるとちょっと時間がかかりました・・・。紙に書けば一瞬だった。こうすると、各レコードは

AさんがBさんをフォローした場合、（”201002132342″,”A”,”B”）というレコードが、

BさんがCさんをフォローした場合、（”201002132348″,”B”,”C”）というレコードが作成される。

こうすることで、すべてのフォロー関係を１テーブルで管理することができるようになる。自分が誰をフォローしているのかを知りたければこのテーブルから（where フォロー元ID＝A）で3列目を抽出すればよいし、自分をフォローしてくれているアカウントを抽出するには（where フォロー先ID＝B）で2列目を抽出すればよい。

これらの３テーブル

①アカウント一覧テーブル（全ユーザのアカウントを管理。アカウントID、パスワード、アイコン、各種プロファイル）

②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID、アカウントID）

③＋④フォロー関係一覧テーブル（登録日付、フォロー元ID、フォロー先ID）

で、ユーザーごとにテーブルを作成することなく、スケーラブルな対応ができるようになるわけだ（たぶん）。

厳密には、運用上無限に肥大化し続けるテーブルは扱いづらいため、つぶやき一覧テーブルなんかはレコード数単位で分割されていると思う。アカウントを発行するときにでも、①のアカウント一覧テーブルのカラムに、書き込み先のつぶやき一覧テーブルの識別番号を与えているかもしれない。またはテーブル自体は仮想的に一意の名前にして、実際にはIDのレンジでテーブルをパーティショニングしているかもしれない。あと、リストの管理とかもあるし、当然これだけでは済まないのは理解しています。

というわけで、勝手にTwitterのテーブル構造を予想してみましたが、これはTwitterがOracleやMySQLのようなリレーショナルデータベースを使っていたら、の話。GoogleのBigTableのような別のアーキテクチャを使っていたら、これらは全然違うだろうし、BigTableを理解していないので推測もできません。ただAPIを使ってTwitterアプリを作ってみたら、いちいち予想しなくてもわかりそうな気もする。作ったことないし、作る予定もないので永遠に推測の域を出ませんが。誰か正解知ってるのかな。

たまにはDBマガジンでも読んでみるかな。トレンドはキャッチアップしておかないとね、モチベーションがあるうちに。

Google App Engine for Java [実践]クラウドシステム構築 (WEB+DB PRESS plus) (WEB+DB PRESSプラスシリーズ) (WEB+DB PRESS plusシリーズ)

技術評論社 2009-09-10
売り上げランキング : 17213

Amazonで詳しく見る by G-Tools

Posted in Twitter, Web, デザイン, 日記 | No Comments »

川本真琴の新曲とPANDA

Posted on 2月, 12 at 4:19 pm

PANDA1/2の記事を書いた矢先に、川本真琴が新曲発表ですよ。9年ぶりって・・そんなに経つのか・・・。

音楽の世界へようこそ
川本真琴 feat.TIGER FAKE FUR

(株)ディスクユニオン 2010-02-19
売り上げランキング : 48

Amazonで詳しく見る by G-Tools

さらにPANDA1/2の記事を書いた矢先に、上野動物園にパンダ復活ニュースですよ。

上野動物園にパンダ＝１１年に中国から２頭－東京都
東京都の石原慎太郎知事は１２日の記者会見で、上野動物園（台東区）にジャイアントパンダのオスとメス１頭ずつを２０１１年に受け入れることで中国と大筋合意したと発表した。中国側から貸与を受け、都が年間９５万ドル（約８５００万円）を支払う。（2010/02/12-15:48）

http://www.jiji.com/jc/c?g=soc&k=2010021200683

やっぱりいいタイミングなんじゃないの？パンダ。

Posted in マーケティング | No Comments »

PANDA 1/2の話を聞いてきた

Posted on 2月, 12 at 2:14 pm

今年はパンダがくる！ということで、旧友のJamesPandaJr.から話を聞いてきた。今youtubeで聞けるのはコレ。川本真琴「1/2」のカバーです。川本真琴大好き（でした）。

企画を見せてもらったのですが、とてもよく練られていてステキです。帰り際にJamesPandaJr.のパペットももらえたし。2010年は中国で万博もあることだし、上野動物園にもパンダが来るかもしれないですし、パンダブームがきそうですよ！ということで応援しています。

[ポーケン / Poken] – Panda

Poken SA (Switzerland)
売り上げランキング : 24942
おすすめ平均

Amazonで詳しく見る by G-Tools

Posted in マーケティング | No Comments »

夕焼けが山火事にorz

Posted on 2月, 12 at 1:47 pm

夕陽を撮ろうと思って頑張ってみたんですが、なんか山火事みたいだ・・・orz。
EOS kiss X3では最大のシャッタースピード1/4000にしてみたものの、なかなかイメージしていた写真は取れないみたい。うむむ・・・

Canon デジタル一眼レフカメラ Kiss X3 ダブルズームキット KISSX3-WKIT
	キヤノン 2009-04-24 売り上げランキング : 611 おすすめ平均使用感抜群使いやすいカメラいい買い物でした！ Amazonで詳しく見る by G-Tools

Posted in 写真, 日記 | No Comments »

nanoblockで脳内活性化

Posted on 2月, 12 at 9:44 am

誕生日プレゼントでキクからもらったnanoblock。こういう指先を使うおもちゃが自分は好きなので、前にもペーパークラフトにはまったりしていろいろ作ってたわけですが、

ペーパークラフトは凝れば凝るほどパーツが細かくなって、肩がどうにかなってしまいそうだったので、もう少し気楽に遊べるものは、ということで、キクが見つけてくれたわけでございます。

で、以前はこんなの作ったんです。インコ。

とか、カエル。ちょっと色がアレですが。

とか、携帯電話とか。

で、久しぶりに作ったのは、自転車。

わりと走りそうでしょ。ちなみに高さは5センチぐらいです。

次に、グランドピアノ。

自転車は、作り方マニュアルがあったのでそれを見ながら忠実に再現してみたんですが、グランドピアノは、「こんなのも作れますよ」的な感じで完成写真はあったんだけど、マニュアルがないので、完成図だけ見て、あとは想像力で制作。あ、ちなみに公式サイトにざっくり作り方が掲載されていました。

http://www.diablock.co.jp/nanoblock/blog/nano_5.html

まあこれだけで見ても、普通はなかなかうまくいかないもんです。また、勝手にアレンジしたほうが、楽しいしね。

nanoblock BASIC SET

河田 2009-09-25
売り上げランキング : 1635

Amazonで詳しく見る by G-Tools

Posted in nanoblock, デザイン, 日記 | No Comments »

youtubeにHD動画をアップする練習

Posted on 2月, 12 at 8:52 am

HDバージョンでアップ。ようやくこなれてきた感。あとは自宅PCのスペック次第だが、やっぱりHD動画のエンコードや編集はPCも苦しそう。HDとは・・・・HDTVをご参照ください。

もうちょっとさくさく動くといいんだけど。PCのスペックの問題ですかね。

Posted in Web, Youtube | No Comments »

キヤノンのEOS Kiss X4

Posted on 2月, 9 at 9:37 pm

EOS Kiss X4が発表されたとです。

キヤノン、1,800万画素CMOS搭載の「EOS Kiss X4」

～SDXCや動画のマニュアル露出に対応

EOS Kiss X4

キヤノンは、フルHD動画記録に対応したエントリー向けデジタル一眼レフカメラ「EOS Kiss X4」を2月26日に発売する。価格はオープンプライス。

店頭予想価格はボディのみが9万円前後の見込み。「EF-S 18-55mm F3.5-5.6 IS」を同梱するレンズキットは10万円前後、レンズキットの内容に加えて「EF-S 55-250mm F4-5.6 IS」をセットにしたダブルズームキットが13万円前後、新たに「EF-S 18-135mm F3.5-5.6 IS」をセットにしたレンズキットは13万円前後の見込み。

引用元: キヤノン、1,800万画素CMOS搭載の「EOS Kiss X4」 – デジカメWatch.

年末にX3を買ったばっかりで、まだまったく使いこなせていないのでそんなに興味もありませんが、そんなに大きな進化ってなさそうな気がします。素人的には。そもそも今のモデルですら使いこなせるのか？自分。

X３もまだまだ販売継続するみたいなので、まずは使い倒せるまでいろいろ勉強です。

Canon デジタル一眼レフカメラ Kiss X3 ダブルズームキット KISSX3-WKIT

キヤノン 2009-04-24
売り上げランキング : 28
おすすめ平均

Amazonで詳しく見る by G-Tools

Posted in 写真 | No Comments »

Youtubeの最適なアップロード方法を理解（備忘録）

Posted on 2月, 9 at 11:15 am

youtubeへの最適なエンコード方法をようやく理解。

16:9の比率でresize可能な方式にしたくて失敗続きでしたが、ようやくわかった・・・。まあ、このスペックを最初に読んどけって話なんですね。すみません。あとはHD対応でカンペキだ。

http://www.google.com/support/youtube/bin/answer.py?hl=jp&answer=132460

映像
解像度	推奨: 動画の元の解像度 – HD では 1920×1080（1080 p）または1280×720
ビットレート	ビットレートはコーデックに大きく依存するため、推奨値や最小値はありません。動画は、ビットレートではなく、解像度、アスペクト比、フレームレートで最適化してください。
フレームレート	リサンプリングは行わず、元の動画のフレームレートを維持するようにしてください。プルダウンなど、フレームレートをリサンプリングする手法は一切使用しないようにしてください。
コーデック	H.264 または MPEG-2 を推奨
推奨コンテナ	FLV、MPEG-2、MPEG-4
音声
コーデック	MP3 または AAC を推奨
推奨コンテナ	FLV、MPEG-2、MPEG-4
サンプリングレート	44.1 kHz
チャンネル	2（ステレオ）