上周处理过一个案例。我们博士找到我说一个实时精准推荐场景，需要我帮忙一下。我听她描述，首先经过大数据系统查询用户订单情况得知他买过什么？还要通过大数据系统查询用户看过什么？然后结合他买的和看的推荐商品。
我问：“这是不是就是一个类似猜你喜欢的？”答：“是”。我又问：“要实时？”答：“最好实时或者准实时。”我说现在这样设计不可能啊？ 那个大数据系统走一次几个小时。博士说现在的确如此，几天更新一次买过什么。所以听到这里大家知道了背景吧。
当然之所以要走大数据这就是我一直以来说的那句话，单机（套）是最好的架构。数据库几十个，商品、订单、行为等等无法做到跨库查询，怎么办？数据集中。
数据集中可以实时吗？可以也不可以。对于关系型数据库可以，对于hadoop全家桶成员有的可以，有的不行。这个不行主要还是hive自身缺陷，不支持写。这就天生注定了，只能定时合并。
我给出的方案是（本案例恰好，商品和订单都是MySQL，我采用多源复制的方案进行了数据库的实时汇聚。如果是遇到Oracle PG等，其实异构数据库也是可以通过CDC技术来实时汇聚）。对现有SQL进行改写，目前是30多万数据中选出50条，其实这已经是海选，不是精准了。何为精准推荐，就是只推荐1-2个，数量在于精，而不在于多。我个人认为50个其实效果还不如5个好。但是先解决30万的问题。
select 商品属性 from 商品表 where 商品卖家 ='123' and 商品新上架时间>='2022-10-21 00:00:00' and （一个买家用户买过的商品属性 or 还是一个买家用户看过的商品属性）这里买过的属性是从订单表中拿，而且拿最新的一条。看过的属性从行为表中拿，而且拿最新的一条。也就是说等于拿着两条数据特征去商品表中找，很容易很快。
我在实际环境中测试了一下，平均30毫秒。其实这里最难的无非就是商品、订单和行为是三个数据库。如果都是一个数据库，更加简单了。
本案例典型的使用数据库直接完成实时的精准推荐。虽然速度不是最优，但是还可以吧。要让用户体验好，必须在数据库段压到100毫秒内，这样给网络和其他环境留下空间。
我比较得意的点在于，逻辑清楚，而且真的还算快。没有中间环节，没有拖泥带水。直接数据库镜像复制解决。
很多时候数据库本身不慢，但是如果设计无用的太多，那才是真的让他慢。
