token token token フォーラムのプライバシー問題から。
現在のdashboardは以下の４つの要素が組み合わされています。
統計ＤＢの仕様： wiki:集計サーバ
dashboardで使われているSQLから判断。内部処理は未検証。
動作に必要な情報、プライバシーに関わる情報
初期ノードをクライアントに公開するためのもの。ここはプライバシーに関わる内容を扱うので対処が必要ですね。
積極的プライバシーに関わる情報？
ファイルがどれだけDHT上にあるかどうかをカウントするだけ。
多分、user_logと関連があります。
ここでlogoutになったノードに紐付くonline_dataは削除されるんじゃないかな。そうでないと、online_dataから取り出す値が増え続けてしまう。
dashboardからは使われてない。GenkidamaクライアントのDHT制御用？
積極的プライバシーに関わる情報？
『誰（暗号化されたノード情報）がどのように動画を再生したか』が書かれていて
で使われている。
現在では、DBで小細工せずに、個人由来の情報を暗号化してノードを区別するkeyにしている。
個人由来の情報はクライアント側に封入するので、統計サーバで暗号化済ノード名（暗号化した個人由来の情報）を保持する必要がある部分は、global entriesに限られてくるんじゃないかと。と言う事で、DBスキーマの改善案を以下に示す。
global history用に cache/dht/directを列にし、それぞれをカウントアップしていく方式に変える。テーブル名も変える必要があるが、とりあえず他のサービスに対応してもサービス依存の文字列に縛られなくなり、依存性除去が出来る。それに、Genkidamaとしてはcache/dht/directの３要素が数値で解れば十分だと思う。また、ネットversion毎に統計サーバを分けるなら、version列は要らないんじゃないかなぁ。
nico_video_access_log
| id | 主キー |
| datetime | 日時 |
| SHA1(IPアドレス:ポート番号) | |
| バージョン番号 | |
| video_id | ビデオID |
| アクセス種別(ローカル、DHT、本家） | |
| cache | 整数 |
| dht | 整数 |
| direct | 整数 |
| SHA1(キャッシュURL) | |
| isLow | true/false ( or 1/0) |
ついでに、lowと非lowは文字列で判断するんじゃなくて、専用の列を用意してみるとか。区別しない場合は、単純にdistinct(video_id)すればよいし、区別する時はisLowを見ればよいし。
global entriesは、online_dataから取れば良いと思う。今後他のサービスに対応するなら、online_dataにサービス名を追加して扱う方が良さそう。online_dataの有効性を決める為には、『誰が何を公開しているか』を知っている事とuser_logとの兼ね合いで、暗号化済ノード名は必須になる。
online_data
| id | 主キー |
| datetime | 日時 |
| hash | SHA1(IPアドレス:ポート番号) |
| バージョン番号 | |
| key | キー(video_id) |
user_log
| id | 主キー |
| datetime | 日時 |
| hash | SHA1(IPアドレス:ポート番号) |
| バージョン番号 | |
| status | ログイン、ログアウト |
global rankingは、global history用の改造案を元に導出（cache/dht/directの合計）すれば良さそう。
と言う事で、プライバシーに関わる情報を扱うのは
の３つに狭められる。
token あ、マイナーバージョンの方か。バージョン通知の案に使う為に、マイナーバージョンの列をどこかに残すとするなら、online_usersに残しておけば、残りのテーブルにはバージョン列を持たせなくても良いかも。
syuu 前提として、利用動向を把握するのが集計サーバの目的でDashboardは集計したデータをユーザにも還元するのを目的としてあのような情報を提供しているので、Dashboardで必要ないからといって記録するデータ量を削る必要はないと思ってます。 逆に、ユーザの許容範囲内で最大限記録をとっておいた方が良い。 取り合えず取っておいて、どのように使うかは後から考えるという感じ。
なので、ローカルから取ってこれるから集計サーバに記録する必要なし、とはならないと考えています。
但し、DBスキーマは結構汚くなってるから調整する必要はあると思っていて、上述の変更は妥当なんじゃないかなと思います。
token >なので、ローカルから取ってこれるから集計サーバに記録する必要なし、とはならないと考えています。 じゃあ、プライバシー問題は全て任せたよ。
token thumbinfo.xmlはどう扱おうか。
これまでの話をまとめると、クライアントでcache生成するときにthumbinfo.xmlも取ってきて、DHTにputする。ついでにxmlrpcにも送る。その後、サーバ内でthumbinfo.xmlをファイルで利用するのか、DBに突っ込んで利用するのか。
使い勝手を考えると、DBの方が良いかな。ファイルでもいいかと思ったけど、検索に弱いから応用性が低いな。global entriesのようなvideo_idだけでその他のデータを取ってくる処理だけを考えると、ファイルでも良いんだけど、その中身を横断的に検索しようとするとファイルじゃ面倒だね。ファイル開いてXPathで抽出箇所指定して、中身を検証ってのの繰り返し。それならDBで値を持ってて操作はSQLでやって、ってのの方がシンプル。
token を作成。
token token wiki:DB再設計案 ここに、必要だと思う項目を理由と共に追加してくださいな。また、改善案の各項目の下側に、更に改善案のスキーマを追加して議論していきまっしょ。
token どうも噛み合わないと思ったら、用途が違うんじゃん。と言う事でwikiの方は白紙に戻す。
Dashboard用とログ用は別々にするしかないね。ダラダラととったログを入れておくのと、表現用の理路整然としたＤＢと分けたいね。そうでもしないと、どうも、共用じゃ扱いにく過ぎる。
なので、ログ用はid:syuuの方で考えて。Dashboard用はこっちで決めるから。と言っても、Dashboardに必要なデータ群くらいの抽象度にしとくわ。
token wiki:DB再設計(Dashboard)案
を作成。
の方を復元しても良いけど、dashboard案が盛り込んであるので何をuniqueにするとかどのデータをまとめるとか、という案はそのままでは使えないと思うので、id:syuu側で自由にして欲しい。
token syntaxがエラーするので、名称変更。
token 完全に分けてしまうというより、ログ用から取れるデータは取る、取り難いデータは整形してＤＢに突っ込んだ後で取る。という考え。
Genkidama
文字列操作がパフォーマンスを落としてるかもしれないのと、アイデアを色々試すにはちょっと堅い設計なので、もう少し柔軟にしてみる。