查看原文
其他

网上所谓的大厂分库分表,都是错的!

破产码农 InsideMySQL 2022-10-13
点击卡片,关注 InsideMySQL
问各位小可爱一个问题:什么是分库分表?
这是个有意思的问题,因为姜老师发现分库分表是中国特色数据库才有的定义,你在英文文献中找不到对应英文单词。
一言以蔽之,分库分表就是是将数据分片(Sharding),从而提升数据库的容量。
注意,这里的容量是指存储容量和性能容量
第二个问题,为什么要进行分库分表呢?
我们来看下知乎上,华为云开发者社区的回答。

可以看到,华为云开发者社区认为 MySQL 数据库单表的上限是1000万内。
若超过,则从性能考量,需要进行拆分处理。
然而,以上全错
MySQL 单表的存储上限是64T。另一方面,单表 1000W 和 5000W的性能几乎一样,没有太大区别。
这是个非常有意思的话题,所以姜老师就在 IMG 微信群发起了投票,看看 IMG 小可爱们的投票结果
不好意思,投票的不是她们。投票结果应该是:

IMG 群的小可爱对于大数据的定义就高多了,认为超过1亿才需要进行分库分表的同学占比达到了63.2%。
认为超过1000万就需要进行分库分表的同学占比32.3%。
然而,竟然有4.6%的同学会认为超过100万就需要进行分库分表!
请问你们是负责的是 PostgreSQL ,又或是 TiDB 数据库么?
即便上述所有选项,答案依然是:以上全错
但凡用单表记录数去评估是否需要进行分库分表,都是错的。
1000W的表,和100亿的表,访问单条数据的性能是差不多的。因为都是B+树索引的数据结构。
B+树索引高度为3和5,也就0.0003和0.0005秒,看似慢了近1倍的时间,但从业务角度看并没太大影响。
衡量是否需要进行分库分表的标准有且仅有:容量。
这里的容量是指存储容量,性能容量。
容量不是瓶颈非要去做分库分表设计,那就是脱裤子放屁,多此一举。
当然,这里只谈技术环节,不谈商业逻辑。
因为如果你能像理想汽车那样,用三流的技术,二流的用户体验,卖出一流的价格,那是一种非凡的本事。
so,姜老师不屑的一直是 TiDB 这样架构的数据库,对 TiDB 公司我无比尊敬。


网上所谓的大厂分库分表,大多都是错的,包括大厂本身
大厂即便是错,那最多也就是过度设计。
大厂有一堆分库分表的配套组件,用起来已经相对顺手。
再次强调,分库分表的第一性原理是:容量,存储容量和性能容量。
没有容量规划,谈分库分表都是空谈。

让每天增量1万条记录的业务表做分库分表设计,那就是扯蛋;

让每天高峰 QPS 1000 的业务去做分库分表设计,那就是蛋疼;

天天跟你谈分库分表,分布式架构有多香的人,赶紧让他滚蛋。

核心业务系统才需要精心设计的分库分表方案。
即通过分布式架构解决传统单一 Oracle 数据库的瓶颈。
写到这,姜老师已经 call back 好多次关于分库分表的前提:容量,存储容量和性能容量。
存储容量比较好理解,那就是单一数据库实例的存储是不是瓶颈?
举个例子,监控系统每10秒收集一批监控数据,数据大小为8K。假设你的监控系统负责下面1000台服务器的上报,那么每天的存储开销为(这里不考虑压缩问题):
(6*10*8K) * 24 * 60 * 1000 ≈ 70G
若磁盘大小为2T,那么监控数据库仅能存放约30天时间。
若要存放超过30天的数据呢?
最简单的是仅保留30天的数据,30天前的数据删除。
但是如何快速删除30天前的数据呢?
用 DELETE 操作是很慢的。
所以,可以按天分表,线上保留30天的表。
然而,若业务发展,监控的服务器数量从1000台变成了1500台呢?保留到15天?
这时,可以考虑分库,分成100个库,每个库保留30天的数据。分库的规则可以根据监控服务器ID进行哈希
然后把这100个库放到1个、10个、还是100个数据库实例,那可以根据容量来进行具体规划。
如果是前面的例子,1000台到1500台,那么根据分库分表的设计,可以每个数据库实例存放50个库,每个库都保留30天的数据。
上面的这个分库分表设计是一个拥有两层的数据分片策略。第一层根据每个服务器ID分片数据,第二层是根据日期再进行数据的分片。
第一层分片可以很好解决存储容量的瓶颈问题,第二层分片用于方便解决日后的数据清理工作。



当然,分库分表设计最重要的是解决性能容量问题,这才是核心业务系统最为关心的内容。
我们来进行性能的容量规划~~~
下图是天猫公布的双11订单数据:
不好意思,手抖了,应该是:

对于数据库来说,对应的峰值 TPS 应该就是58.3W
若单台数据库服务器的性能上限是 3000 TPS,则需约200台服务器才能满足业务的需求,而这还仅仅是天猫的量。
可以看到,单实例数据库就是会存在性能瓶颈,即便用 Oracle 数据库也解决不了问题。
因此,这时需要引入分库分表的分布式架构设计,通过水平扩容(Scale Out)的方式解决性能容量问题。
这也是分库分表最有意义的场景。
然而,试问又有多少企业真正存在如此的性能容量瓶颈呢?

思考题


其实通过分库分表设计去解决存储容量瓶颈并不是最优的设计,而且会引入很多额外的问题。
例如需要对数据进行汇总查询,又或比较2台服务器监控数据的差异等。
这是因为分片后数据有很大概率分布在不同服务器的不同表中。
那么对于存储容量是瓶颈的表结构设计,除了分库分表,最优的设计应该是什么呢?
欢迎加入 IMG 官方社区高端群,这里会有思考题的标准答案哦!
IMG仅限码农入群,猎头或其他行业勿加。
入群请加姜老师个人微信 82946772,并备注:码农入群


本公众号最早于2015年创立,已经陪各位同学走过了7年的时间,总计有4个微信群:少林、武当、峨眉、华山。
其中不少同学姜老师都是看着从初出茅庐的技术小白跳槽到大厂、然后开启逆袭的人生,买房、结婚、生娃、买二套房、跳槽、移民......
很荣幸,也很开心,姜老师是真心希望能带着每个 IMG 群的码农起飞,过上理想中的生活。
7年时间,变化真的很大,数据库也已经进入到 NewSQL 时代。
现在呢,希望各位同学能跟随姜老师进入到 NewDev、NewDBA、NewOps的时代,也就是我们的 IMG 官方社区高端群
IMG 官方社区高端群是年费制的,不过也就99元/年,权当请姜老师喝杯咖啡。
但在会员期间你可以享受到下面的福利:
  • 突破微信群人数500的限制,以后所有高端群小伙伴可以在一起吹水;

  • 提供 IMG 公众号每篇技术文章最后遗留问题的标准答案;

  • 技术圈的江湖八卦,比如某数据库出局某行的原委,某大V被新领导GZ;

  • IMG社区技术嘉年华大会门票5折优惠;

  • 姜老师夫妇的私密分享,包括技术、工作、投资、相亲、移民等热门话题;

  • 会员每邀请新会员入群,可以享受59元的返利(把年费赚回来😄);



往期推荐



数据库已进入到 NewSQL 时代,你是不是也已进化到了 NewDBA?NewDevOps?

如何正确地关闭 MySQL 数据库?99%的 DBA 都是错的!

国外教授怒怼国产数据库,但我觉得是他格局小了

ClickHouse 将会是 OLAP 最亮的仔!

Oracle、 PostgreSQL DBA们,你们过得还好么?

来试试这道 MySQL 面试题吧,比 Leecode 好玩多了~~~

从职高到麻省理工计算机博士,他是传奇!


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存