Home | 简体中文 | 繁体中文 | 杂文 | 知乎专栏 | 视频教程 | bilibili | Github | OSChina 博客 | 云社区 | 云栖社区 | Facebook | Linkedin | 打赏(Donations) | About
知乎专栏多维度架构 | 微信号 netkiller-ebook | 51CTO:视频教程

8.2. 常规操作

你在网上看到关于分库,分表方案几乎都是从技术维度出发,例如解决大数据存储压力,提高查询性能等等。面试中我发现很多架构师对分库分表也只是停留在对分库分表中间件理解和应用上。

任何系统数据流都是漏斗形状的,数据库是漏斗末端,架构设计是尽量在前端计算,合并,拆分,分流,缓存,最终将有价值的数据写入数据库。数据库的访问是结果集越小越好。

基于这种认识,通常分库和分表,我们想到的就是首先垂直分表,这种方式简单易操作。

		
当前(本年度数据库)(热数据)
2019年数据
2018年数据
以此类推

或者按照月份分表

当前(热数据)
10月数据
9月数据
以此类推
		
		

这样分表可以缩小结果集,能快速解决查询瓶颈问题。但是新的挑战来了,由于分表后,索引是独立不连续的,历史数据的查询或遍历数据变的复杂了,要么使用联合查询,要么一张表一张表的遍历。

同理水平分表也是粗暴的将一些尺寸较大的列独立成新表,以降低单个表的容量尺寸。

如果是单纯的数据查找,还是能忍受,我们可能根据时间来选择查询的表,如果是复杂的SQL操作,就只能逐一查询,在程序中二次计算,合并等等操作。

这种分库或分表的思路,理论上属于数据归档。将热数据放在当前数据库中,将很少查询的冷数据放在另一个库中。但是对于 user 这种表就无能为力,你不知道那个用户什么时候会做登录操作。

网站:http://www.netkiller.cn/ | 知乎:netkiller | 51CTO:视频教程 | Bilibili:netkiller | Github:netkiller