(一百)大白话当分库分表技术方案运行几年过后,再次进行扩容应该怎么做?

今天是数据库分库分表的最后一个环节,也就是数据库扩容这块,其实分库分表本身并没太大的难度,大家从石杉老师面试突击第一季听了一些基础的方案之后,然后加上这里讲的几个案例,大致就知道应该怎么做了,我认为,分库分表这块真正难的地方,应该是在于真实的实践经验,就是大家最好是在学习过后,真正到自己的业务场景里去思考一下。

看看在自己的业务场景下,如果业务表搞成上千万数据的大表,此时各种查询性能如何,完了如何分表,按什么字段分,是否要建立索引映射表,跨库跨表的查询应该怎么做,选用什么数据库中间件,然后如何进行数据迁移,最后就是如何进行扩容。

这些细节最好大家是能够在自己负责的项目里去实践一下,那是效果最好的。

因此最后我们给大家谈一个话题,就是如果你分库分表了,比如搞了几个数据库服务器,每个服务器上部署了一个数据库实例,然后你的业务库拆分在各个服务器上,你的业务表拆分为几百上千个,每个服务器上都有一部分。

此时如果过了几年后,你每个表的数据量都增长到了一定水准,比如刚拆分的时候每个表才100w数据,结果过了几年,每个表都增长到了几百万数据,此时应该怎么办?还能怎么办!当然是把表进一步拆分,增加更多的表了!

完了增加更多的表之后还得把数据做迁移,更改系统的路由规则,极为的麻烦。

那大家觉得真的应该出现这种情况吗?其实完全不是,咱们应该从一开始,就对上述情况say no,也就是说,刚开始就完全可以多分一些表,比如你数据量有10亿级,那么你可以分为10000个表,每个表才10w数据,而且后续你计算好增量,可能10年,20年过后,单表数据才百万级。

那么此时是不是就不会出现上述情况了?

所以说,从一开始,你的表数量宁愿多一些,也别太少了,最好是计算一下数据增量,让自己永远不用增加更多的表。

其次,万一是过了几年后,你的每一台服务器上的存储空间要耗尽了呢?或者是写并发压力太大,每个服务器的并发压力都到瓶颈了呢?此时还用说么,当然要增加更多的数据库服务器了!但是增加服务器之后,那么你的表怎么办呢?

简单,此时你就得把你的表均匀分散迁移到新增加的数据库服务器上去,然后再修改一下系统里的路由规则就可以了,用新的路由规则保证你能正确的把数据路由到指定表以及指定库上去就没问题了。

因此关于数据库扩容这块,虽然网上有很多方案,但是我们建议的就是,刚开始拆分,表数量可以多一些,避免后续要增加表。然后数据库服务器要扩容是没问题的,直接把表做一下迁移就行了,然后修改路由规则。

猜你喜欢

转载自blog.csdn.net/zht245648124/article/details/129560745
今日推荐