表与表之间的关联基本上是所有业务系统都存在的,RDBMS通过外键实现,MongoDB通过嵌入式子文档解决,那么Elasticsearch怎么解决这个问题呢?答案就是Parent-Child关联(参考文档)
业务场景
有一个广告的分发系统,为了更精准的做广告的推送,除了自身积累的数据以外,还会从其他合作方通过数据交换(当然这些都是脱敏的数据)的方式获取更多用户行为数据,例如从音乐网站获取听的音乐列表、从购物网站获取最近的购物类别、从书评网站获取最近浏览的图书等等。这些来自于外部的数据,有以下几个问题:
- 并不是每个用户都有全部的数据,比如有些用户只有书评和音乐信息,而有些用户没有任何外部信息
- 某一类外部的数据源可能包含几个网站,比如音乐网站有A、B、C三个网站,它们提供的数据格式也并不一致
在进行广告推送时,需要实时查询一个用户的信息完成精准推荐。比如实时查询满足下面条件的用户:
- 最近一个月,
- 经常在早上、傍晚或者晚上连续一个小时的音乐;
- 购买过跑鞋、运动手表等跑步装备
- 且购买过或点评过运动类书籍
再继续下面的(十分简化)解决方案之前,可以先思考下
解决方案
这是典型应用大数据进行个性化精准推荐的应用场景,在省却了数据清洗、评分等各种步骤以后,简化为一个查询问题。分析可以发现数据问题的核心就是:无固定表结构,是典型的Schema-Free的NoSQL应用场景,第一个反应出来的就是MongoDB。
MongoDB
MongoDB用作以上的数据存储,毫无疑问具有天然的优势,可以将每个来源的数据都作为user的一个子文档存储,查询时也只是在这一个Collection上进行(可能有人会说这种方案太蠢了,的确是,不过也要看产品所处的阶段)。当然这样做的问题也显而易见:
为了查询速度,索引是必须要创建的。可是因为数据源不断变化,那么索引的维护就会变成一个灾难。一旦忘记创建查询,可能就会拖死整个系统。
下面当然就是主角上场了。
Elasticsearch
定调:
1. 由于字段是变化,因此必须使用动态Mapping(文档)