DB再設計案 - Genkidama Wiki - Genkidama

Outline

1. ＤＢ改善案
   1. online_users
   2. online_data
   3. user_log
   4. data_log
   5. nico_video_accesss_log
   6. video_info

ＤＢ改善案

• 各主キーに用途を付与
• datetimeがあればレコードの重複は考えられない

online_users

• 初期ノード用
• 利用されてるマイナーバージョンの把握

id	主キー
datetime	日時
address	IPアドレス
port	ポート番号
version	バージョン番号

online_data

id	主キー
datetime	日時
hash	SHA1(IPアドレス:ポート番号)
version	バージョン番号
key	キー

user_log

id	主キー
datetime	日時
hash	SHA1(IPアドレス:ポート番号)
version	バージョン番号
status	ログイン、ログアウト

data_log

これはDHTへのput/getのログ。利用動向を把握し、時間の流れと共にどのようにput/get数が増減するのかを知るためにある。

id	主キー
datetime	日時
hash	SHA1(IPアドレス:ポート番号)
version	バージョン番号
key	キー
status	add、remove

nico_video_accesss_log

サイトによって仕様が違って必要になってくる項目も変わってくると思うので、汎用化出来るかはちょっと疑問。 （例えば、”ビデオなのか。”とか。そこからして違うサイトに対応するかもしれないし。→ねとらじとかねとらじとか） 後からcolumnの追加／削除を試行錯誤するのは大変だし、ここはサイトごとにテーブルを用意しちゃっていいと思う。 まぁ、サイト固有情報をテキストフィールドにXMLで入れるんでも良いけど、そこまで努力する理由があんまり見いだせない。

主キー	id	整数値
unique、外部	video_id	ビデオID（関連：video_info#id）
unique	isLow	true/false
	cache_count	アクセス回数(cache利用時）
	dht_count	アクセス回数(dht利用時）
	raw_count	アクセス回数(直接接続）
datetime	日時

※video_id+isLowは重複不可能なので、uniqueにしたい。

※クライアントは再生毎にvideo_idに関連する各countをカウントアップしていく。

video_info

thumbinfo.xmlの中身をべったり

主キー	id	video_id
..	..	..

これもニコ動固有のDBにして良い。 基本的にサイト毎にDBは有っていいと思う。