今天给大家带来的讨论主题是通过实战经验来对百亿数据量下的多表数据查询进行优化,俗话说的好,一切脱离业务的架构都是耍流氓,接下来我就整理一下今天早上微信群里石头哥给大家分享的百亿数据量多表查询架构以及优化思路。由于本文内容整理自微信群,爬楼不易,整理更不易,如果有遗漏,欢迎大家在评论区留言。
这里我们先举个简单的例子,来个开胃菜,然后再引出今天的访谈主题。
举例:比如我们的CzarCms系统权限系统设计中的两张表:用户表以及角色表,这两张表有关联关系。这时候如果我要取一万个用户的数据,然后用户数据又需要关联角色表来查询对应的角色名称,这时候你会怎么做呢?
按照以往我们的经验我们会对大表进行尽可能的拆分,能分表就分表。我们在取数据的时候使用下join查询即可实现。
可是,当我们的系统变得足够大的时候,假设我们的用户表有一百万的用户了,角色表也有近10万的数据,这个时候我们如果还继续使用Join进行查询的时候就会变得非常慢了!
这时候我们可以改变下思路:就是先把一万条用户数据取出来,然后取所有角色id后再去重的组合,然后用一个查询把所有的角色信息取出来,再在内存中进行相应的拼接处理。 这种思路勉强能够支撑。
可是如果数据量变得越来越大,这时候我们应该如何来进行处理呢?且看下面来自百亿数据实操的经典访谈。
这里,石头哥就以他们公司的实际情况为例来进行了相关的实例阐述: 我们的主要表,都是几亿到几十亿行,一个join不小心就可以弄死数据库, 而且每天1亿包裹在路上,产生3亿多扫描数据 数据存储最少T+1,保存完整的一个月,也就是30到60天 数据量90到180亿 这里面,最常见的就是省,市,区,网点,人员,这5个字段 很久以前,我们只有三五百万业务量的时候,大家都是join五次 后来为了省事,用了10个字段,提前把名称写进去 再后来,发现亏大了 多花了好多空间,并且join不一定是只需要名称字段 于是,进入了新时代,所有数据表都有那基本的5个字段,不许join 查询出来数据后,在内存中再关联省,市,区,网点,人员等信息 地区5万行,网点3万行,人员100万,全部提前加载到内存,加起来不到100M 我们小部门有100台服务器,绝大部分用到这些基础数据 不仅仅上百亿的扫描表,其它业务表,几乎都会带有这些字段,所以,缓存基础数据,不吃亏
吉吉:明白 谢谢 只是举例 这种思路真的很正确 我们总是从技术考虑全部场景却不考虑产品本身根本不能一劳永逸的搞。
今天非常感谢石头哥的精彩分享,相信只有实际的业务操作经验才会有如此深刻的讲解!一切从实际业务出发,脱离理论,实践出真知。还是印证了那句话,一切脱离实际业务的架构都是耍流氓!感谢大家的阅读。
最后为石头哥的XCode打个广告:
NewLife.XCode是一个有10多年历史的开源数据中间件,支持nfx/netstandard,由新生命团队(2002~2019)开发完成并维护至今,以下简称XCode。 xcode在2018年已经完成对大数据场景的特殊优化改造,2019年的目标是是针对分布式数据场景的优化。 最近石头哥也在为XCode编写系列教程: 整个系列教程会大量结合示例代码和运行日志来进行深入分析,蕴含多年开发经验于其中,代表作有百亿级大数据实时计算项目。
开源地址:https://github.com/NewLifeX/X(求star, 670+)