外部記憶装置

ニコニコ動画の裏側

• kenji
• 01:02
• コメントする
• トラックバックする
• カテゴリー:Diary

ニコニコ動画の勉強会とやらがひそかに開催されたらしく、そのレポートがいくつかあがっている。これは興味深い。
ニコニコ動画勉強会に行ってきました

ニコニコ動画の簡単な歴史やサーバ構成、各モジュールの概要などなど。
またしてもLAMP構成( Linux 2.6 / Apache 2 / MySQL 5 / PHP5 )なんだなぁ。
やっぱぱっと作ってぱっと動かすにはPerlやPHPが有利なのだろう。
特にニコニコ動画自体は複雑なアプリケーションじゃないし、開発自体は楽そうだな。
難しいのはやっぱり負荷分散かな。
あと動画投稿部分はどういう処理になってるのか想像できない。投稿されたビデオをデコードして、再エンコードしてるんだろうか。ビデオ再生のコーデックのライセンスがどうこう言ってた記憶があるのでその辺はライブラリを単に使用してるだけだろう。最近画質がよくなってエンコード職人が出てきてるのでその辺自由度が高くなったのかもしれない。一度ビデオを投稿すればどうなっているか大体わかるか。

興味深かったのは
> 複数テーブルにまたがるJOINは避ける 非正規化ロジックで対応
って所。Mixiの時もあったけどJOINはやっぱダメらしい。MixiもJOINせずに複数回問い合わせのほうがベンチマーク結果的によかったようだ。ふ～む、DBは正規化こそ正義!と考えていたが、どうやらその考え方は古くなってしまったようだ。もちろん通常の業務アプリを作るときは正規化必須で、こういうスループットが重要視されるようなシステムが特殊なのかもしれないが。
今趣味のプログラミングでスループットが重要なWebアプリを作ろうかとしてDB設計してるんだけど、情報を正規化せず冗長なデータ保持でひとつのテーブル見るだけで表示する情報がすべて得られるような設計にするべきだろうか。
いずれにしろWebアプリ作るときはDAOパターンを使おうと思っているので、その辺正規化するか冗長にさせるかはDAO層で吸収できるし気にせず作り出してもかまわないかもしれないな。

「非正規化ロジック」という言い回しが気になったけど、非正規化DB設計ではないんだろうか。
たとえば正規化されたテーブルをJOINするのではなく、２回SELECTするのか冗長なテーブルを1回SELECTするかの違い。
前者は正規化はするが、ロジックで行う。Mixiはこのタイプらしい。
後者は正規化自体をしない。ロジックは関係ないが・・・。
非正規化ロジックというのが何を指しているのかよくわからない。「非正規化ロジック」でググッても今回の記事関連しかヒットしないので、世間的に通用する単語ではなさそうだ。
一度DB設計がどんな感じになってるのか見てみたいな。

後コメントの保存がRDBを使わずCSVって言うのがすごい。
CSVにしたのは何でだろう。DBサーバの負荷を下げるぐらいしか理由が思いつかないが。
MySQLでよくある１台の書き込み専用DBに対してレプリケーションを行うって構成じゃコメントの書き込みが多すぎるということだろうか。
コメントのバックアップはしてないというコメントもあるし、割り切るところは割り切るって言うことなんだろう。

メッセージングサーバの通信方式の「a. 双方向 chunked content-transfer-encoding」は知識が無いのでなんともいえないけど「c. polling 」ってのはどうなんだろう。
ブラウザの挙動から推測すると新規メッセージの受信はpollingでは無く、cometで実装されてるような感じが。常に「XXXから読み込んでいます。」って言う表示があるってだけが根拠だけど。
再生人数はポーリングで一定時間ごとに変化しているようだ。そんなところまでリアルタイムにせんでも・・・と思うがこだわりがあるのだろう。

こういう動画投稿系サイトはスケーラビリティと負荷分散。それと通信費が問題なんだろうな。
ニコニコは回線代などで１年でサマージャンボ宝くじが当たったぐらいのお金が投資されてるということだけど、どこでそれらを回収するかが問題だ。
どうビジネスにしていくかはこれからと言う事で、末永くサービスしていってほしいのでがんばってほしいところ。会社側としたら著作権などでリスキーなビジネスのようだが・・・。

ということでニコニコ内部のシステム構成など興味深い内容だった。とても勉強になる。ありがたやありがたや。