「○○を見ている人は○○も見ています」のようなレコメンドシステムの要件があった場合のデータ処理プロセスを考えてみました。
- ロギング
商品の閲覧ログを記録するテーブルを作成しユニークユーザを識別するcookie値を記録する。
商品ID | 日時 | Cookie
--------+-----------------------+--------------
000001 | 2012-12-15 12:00:05 | AA0000012326
000002 | 2012-12-15 12:10:05 | AB7890987001
000001 | 2012-12-15 12:11:05 | AB7890987001
000003 | 2012-12-15 12:12:05 | AA0000012326
000001 | 2012-12-15 14:12:05 | AA0000012326
000004 | 2012-12-15 15:45:09 | AB7890987001 - バッチ処理1
閲覧ログから商品ID毎にユーザ(Cookie)リストを抽出し更にそのユーザが見た他の全商品IDを抽出して別テーブルに書き出し。
商品ID1 | Cookie |商品ID2| 日時
--------+-----------------+--------+---------------------
000001 | AA0000012326 | 000003 | 2012-12-15 12:12:05
000001 | AB7890987001 | 000002 | 2012-12-15 12:10:05
000001 | AB7890987001 | 000004 | 2012-12-15 15:45:09
000002 | AB7890987001 | 000001 | 2012-12-15 12:11:05
000002 | AB7890987001 | 000004 | 2012-12-15 12:45:09
000003 | AA0000012326 | 000001 | 2012-12-15 12:00:05
000003 | AA0000012326 | 000001 | 2012-12-15 14:12:05
000004 | AB7890987001 | 000002 | 2012-12-15 12:10:05
000004 | AB7890987001 | 000001 | 2012-12-15 12:10:05 - バッチ処理2
2.で生成したテーブルから同一ユーザが同一商品を見たレコードの重複を排除し閲覧数統計を行って別テーブルに書き出す（最大レコード数は"総商品数の二乗－総商品数"になる）。
商品ID1 |商品ID2| 閲覧数
--------+-------+--------
000001 | 000002 | 999
000001 | 000003 | 999
000001 | 000004 | 999
・
・
・
000002 | 000001 | 999
000002 | 000003 | 999
000002 | 000004 | 999
・
・
・ - レコメンド情報の表示
3.で生成したテーブルから現在見ている商品に関連する閲覧数の多い商品を抽出してページに出力する。
わりと大変な処理の様です。。。
あとこの設計だとリアルタイムには分析できないという欠点があります
コメント