- 主题:请问有人用过clickhouse做标签系统嘛？
号称很适合，无数解决方案都在推荐，为什么我觉得从做用户标签系统的角度clickhouse完全不如mongodb呢？
首先号称clickhouse适合大宽表，也没发现能有多宽，其次还不能随便加列，mongodb还能随便加标签或者属性列
--
修改:Xjt FROM 140.207.167.*
FROM 223.104.212.*
对的，就是这样，这个场景用clickhouse真的合适嘛？
【 在 cestlavie 的大作中提到: 】
: 标签的一大应用场景是做即席分析 圈选用户
:
--
FROM 223.104.212.*
ES肯定不太适合这种标签化的计算
mongodb的好处是对于标签最终结果的存储 人->属性；人->标签 的结构天生就是json化的，而且如果把每个人的tags存为一个数组，后续多标签综合运算，也可以用multikey来搞定。
mongodb的另外的问题是每个collection的index数量有限，还有一致性控制能力很差，用的多了整个数据库的数据就各种乱了
我现在在摸索是否比较适合的架构是：人的属性和标签的计算部分，放ch，而最终结果放mongodb。
【 在 cestlavie 的大作中提到: 】
: 我没用过ch做这个，但是感觉比Mongo合适
: 我们之前是用ES 每天刷数、运维都是问题
:
--
修改:Xjt FROM 140.207.167.*
FROM 140.207.167.*
价格贵啊，全量索引。。。如果有100TB的数据，怎么办？
另外高频数据修改，在ES感觉也有问题，举个例子用户新注册，打开了app，这时候需要马上给用户打上基础的标签，并根据基础标签做个性化推荐。这时候ES没法秒级做到吧（在较多的高频读写场景下）
【 在 cestlavie 的大作中提到: 】
: 为啥不合适？
: ES可以理解成把Json的每一个字段都加了索引，不管是竖着查还是横着查，都没问题啊
:
--
FROM 140.207.167.*
你说的计算查询和分析查询是什么区别呢？
比如如果把每个用户的属性和标签作为一个大宽表存在ch里，那么我理解无论通过标签表达式圈人，还是lookalike都会很快吧？假设lookalike只是基本的统计学计算，不考虑机器学习
【 在 cestlavie 的大作中提到: 】
: 标签数据本来数据资产里面就是最有价值的那部分数据啊
: 现在市面上没有能一统天下的适用多种场景的存储：
: 一般来说
: ...................
--
FROM 117.136.119.*
嗯，实时圈人用ck，属性更新用aliyun adb或者其他流之类的，计算出来后批量写入ck，最终单个用户碎片化的customer 360查询用redis/mongodb
【 在 suchasplus 的大作中提到: 】
: ck更新比较麻烦
: 如果是实时圈人，不太好用一个ck打天下
: 实时数据更新你根据量级单独搞个别的存储来更新，ck那边定期merge数据
--
修改:Xjt FROM 117.136.119.*
FROM 117.136.119.*