tag系统, 简单来说可能是从互联网抓取大量信息, 生成分类标签;
然后从用户或终端或浏览器等可以获取用户行为的地方获取用户的行为信息, 计算出用户在各类标签中的匹配值(例如0-100), 例如经常浏览男士用品的或者大量安装游戏的用户, 在男性和游戏玩家的标签下匹配值可能就比较高.
并且标签可能还有时间属性, 例如孕妇标签匹配值很高的用户, 一般有10个月的有效期限, 然后就要贴贴哺乳期的标签了.
年龄标签则随着时间增长.
生成标签的算法, 从用户行为运算出用户和标签的匹配值都是很复杂的. 我们这里要说的不是这个, 而是在整个过程中存储用户和标签信息的数据库.
标签数据库可以选择NOSQL,NEWSQL,DBMS等, 但是要考虑标签系统的独有特性, 数据库要满足才行.
例如 :
table
userid, tag1, tag2, tag3, ...tag20000,.....-- 用户的标签可能会一直增加, 或者到了一定数量后压缩旧的标签这里每个用户一条记录, 每个标签占用一个字段, 在这个字段上存储用户在这个标签上的匹配程度, 时间属性等.
标签系统可以用于定向选择用户, 例如婴幼儿产品的厂商, 可以通过标签系统, 选择和婴幼儿产品相关的用户人群, 发送定向广告.
标签系统最重要的,
1. 提高生成标签的准确度, 精细度, 不断完善, 新增标签.
2. 用户和标签的匹配度算法的效率和准确度. 用户行为信息可以有cookie, feed, 浏览行为, 安装的软件列表, 运行的软件列表等, 从这些信息可以计算出用户和标签的匹配度, 计算结果的准确度越高, 人群的划分就越精准. 而计算效率也是需要考虑的, 如果你的系统支撑了大量的用户, 效率越高, 就可以快速的从用户的短期行为分析出用户最近的标签.
标签数据库比较繁忙的地方 :
1. 生成/更新标签的操作
新用户, 根据用户行为信息计算出用户和标签的匹配值, 对于完全不匹配的标签可以使用默认值. 新用户在数据库的操作是插入新行.
旧用户, 根据用户行为信息计算出用户和标签的匹配在, 该用户可能会产生一个或多个新标签匹配, 也可能在已有标签上的匹配值. 所以有新增列的需求, 或者对已有列更新的需求.
2. 生成目标人群的操作
是一个查询操作, 查询需要结合条件, 例如我们要这样的数据:
select userid from table where
a标签的匹配度>50
and
b标签的匹配度>80
and
c标签的匹配度>60
or
d标签的匹配度>80
limit 10000;
这个查询最终要的是用户ID, 查询条件是某些标签的匹配度.
20003个列的宽表, 在monetdb上的查询效率 :
sql>select count(*) from sys.storage where "table"='t1';
+-------+
| L1 |
+=======+
| 20003 |
+-------+
1 tuple (5.0s)
sql>select id from t1 where c1>1 and c2>1 and c3>1 or c4>1 limit 10000;
10000 tuples (81.377ms)monetdb在TAG系统里使用可能存在的问题.
1. 全表导入/行插入速度, 我这里测试的是2万个列的表. 缺少很慢, 很难接受.
2. 全表导出速度, 我这里测试的是2万个列的表. 缺少很慢, 很难接受.
参考
http://blog.163.com/digoal@126/blog/static/163877040201472962051905/
对标签数据库的要求 :
1. 数据导出速度
2. 数据导入速度
3. 添加列的速度
4. 数据更新速度
5. 数据库扩展性
6. 数据查询速度
[注意]
1. 当列非常多时, 如果查询列很多则查询会很慢(例如一次查询2万个列), 但是如果控制查询列的数量, 例如10个列, 则可以接受.
见
http://blog.163.com/digoal@126/blog/static/163877040201472962051905/
2. 新增列的问题, 当表已经有数据时, 新增列会发生初始化, 所以表的已有数据越多, 新增列会越慢.
参见
http://blog.163.com/digoal@126/blog/static/163877040201472962051905/
[参考]
1. http://blog.163.com/digoal@126/blog/static/163877040201472962051905/