数据蒋堂 | 时序数据从分表到分库

作者：蒋步星

来源：数据蒋堂

本文共5500字，建议阅读10+分钟。
一个物理表的数据量太大时，就会影响查询和计算的性能。

这里的时序数据泛指一切随时间推移而不断增长的数据，比如通话记录、银行交易记录等。

对于数据库来讲，时序数据并没有什么特殊性，可以和普通数据一样放在数据表中。不过，因为不断增长，积累时间较长后，这种数据的量常常都会很大。一个物理表的数据量太大时，就会影响查询和计算的性能。

现代数据库一般都提供有表分区（PARTITION）的机制，就是把一个大表纵向（按行）分成若干区段，分区规则由数据库管理员来设置，对应用程序员来讲是透明的，可以和不分区的表一样访问，数据库会自动根据查询条件决定读取哪些分区的数据，这样的接口体验非常好。

不过，在实战中，分区表的效果在某些场景下并不好，而且使用时也有些约束条件，并不总好用且能用的。结果，在实际业务中，我们常常会看到对于这种大数据采用手工物理分表的方案。

所谓物理分表，就是人为将一个大表分成若干较小的物理数据表。因为时序数据的结构中一定会有一个字段来表示事件发生的时刻，而事件发生的数量一般来讲也会按时间段相对平均分布（大多数情况会缓慢增长，但讨论时可以忽略），所以最常用的方案就是按时间段来做分表，比如一个月数据对应一个分表，这种方式在金融、电信行业比较普遍。

物理分表并不是数据库自动支持的方案，不能对应用程序做到透明，需要应用程序自己处理。在查询数据时一般都会有时间段参数，应用程序可以根据这个参数计算出该查询涉及哪些分表，然后将这些分表UNION起来拼到SQL语句的FROM后面。查询不涉及的时间段对应的分表不会被拼进来，这样就可以有效减少数据遍历的范围，从而提高性能。

这个方案在单个数据库时没啥毛病，但是不是能推广到多个数据库的情况呢？

数据量再大下去，一个数据库也无法承受了，而某些场景下又不允许我们上一套分布式数据库系统，毕竟分布式数据库是个沉重的工程，不仅造价高，而且维护管理都要复杂不少。这时候，我们可以摆多个数据库分别存储数据，类似物理分表的方案，也按时间段把数据分拆到各个数据库中，比如一年数据放入一个数据库中（一般来讲多个库会部署到多台机器上），这样就能分摊查询压力了。

这首先会有一个查询范围的问题，如果查询的时间跨度超过了一个物理分库时，这时候就不能象分表时那样用UNION拼起来了，数据库无法执行跨库的SQL语句。不过，这个问题还不算严重，只是查询明细数据时，要把各个分库的返回数据拼接起来，这并不算困难。甚至，要求前端查询范围必须落在一个分库内也不为过（比如必须先选择查询年份），因为一个分库的数据量并不算少，这样用户体验略有损失，但也可以容忍。

这种方案还会有压力不平衡的问题。

对于时序数据，近期数据的查询频繁度远远高于远期数据，大多数查询都集中在最近一段时间中，存放近期数据的分库上任务就很重，并发较多时仍然会有性能瓶颈，而存放远期数据的分库却几乎没事干，并不能有效分摊查询压力。

还有别的办法吗？

可以采用蛇形分布。比如将多年数据分拆到10个分库中，可以按日期拆分，所有年份中1月1日的数据放到1号分库中，1月2日的放到2号分库，…，1月10号的放到10号分库，1月11号的再从1号分库轮回，…；其它情况的具体分法也可以根据时序数据的时刻字段的分布情况来决定。

这样分下来，每个分库存储的数据量差不多也就是1/n，相对比较平均，还可以规避前面说的数据缓慢增长导致的不平衡；而且，无论近期数据还是远期数据的查询都会被分摊到各个分库中，看起来能够充分利用硬件资源了。

还有点注意事项！

蛇形分布时，每个分库中都有所有年份的数据，几乎每个查询都会涉及到所有分库的数据，不能只挑出某些分库来执行运算，这和前面说的分表方案的优化原理并不一样了。我们需要在分库中继续做分表，查询确实会涉及所有分库，但只涉及分库中的某些分表，这样仍然可以有效的减少查询范围，同时利用分库并行的优势。

第二个问题：每个分库都可能返回数据，应用程序需要把这些数据再做一次汇总，而不能象单库分表那样用UNION推给数据库去完成。对于常见的明细查询，那只要简单拼接再排序就可以了，开发起来并不难；但如果涉及到分组汇总就会麻烦很多，应用程序员并不擅长编写这种运算，这时候最好借助集算器这类外部计算引擎来协助实现跨库汇总运算。

当然，成本和条件允许时直接上分布式数据库就更简单，分布式数据库采用HASH方案基本上可以被理解成是蛇形分布的。

专栏作者简介

润乾软件创始人、首席科学家

清华大学计算机硕士，中国大数据产业生态联盟专家委员，著有《非线性报表模型原理》等，1989年，中国首个国际奥林匹克数学竞赛团体冠军成员，个人金牌；2000年，创立润乾公司；2004年，首次在润乾报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准；2014年，经过7年开发，润乾软件发布不依赖关系代数模型的计算引擎——集算器，有效地提高了复杂结构化大数据计算的开发和运算效率；2015年，润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”；2016、2017年，荣获中国电子信息产业发展研究院评选的“中国软件和信息服务业十大领军人物”；2017年度中国数据大工匠、数据领域专业技术讲堂《数据蒋堂》创办者。

数据蒋堂

《数据蒋堂》的作者蒋步星，从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞，虚拟与现实的相互交织，产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点，站在研发人员的角度从浅入深，进行全方位、360度无死角深度剖析；对于一些业内观点，站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展，站在业内专家角度给予预测和推断。静下心来认真研读你会发现，《数据蒋堂》的文章，有的会让用户避免重复前人走过的弯路，有的会让攻城狮面对扎心的难题茅塞顿开，有的会为初入行业的读者提供一把开启数据世界的钥匙，有的甚至会让业内专家大跌眼镜，产生思想交锋。

数据蒋堂第二年往期回顾：

数据蒋堂 | 存储和计算技术的选择

数据蒋堂 | 人工智能中的“人工”

数据蒋堂 | 中国报表漫谈

数据蒋堂 | 内存数据集产生的隐性成本

数据蒋堂 | 多维分析预汇总的功能盲区

数据蒋堂 | 多维分析预汇总的存储容量

数据蒋堂 | 多维分析预汇总的方案探讨

数据蒋堂 | 数据库的封闭性

数据蒋堂 | 内存数据集产生的隐性成本

数据蒋堂 | 前半有序的大数据排序

数据蒋堂 | “后半”有序的分组