MySql教程

【架构师面试-存储-6】-MySQL分库分表的拆分规则

本文主要是介绍【架构师面试-存储-6】-MySQL分库分表的拆分规则,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

1:单节点MySQL的瓶颈在哪

你是个天才,你浑身是铁,碾的了多少钉子

MySQL单机的存储能力、连接数是有限的,它自身就很容易会成为系统的瓶颈。

当单表数据量在百万以里时,我们还可以通过添加从库、优化索引提升性能。

数据量朝着千万以上趋势增长,再怎么优化数据库,很多操作性能仍下降严重。为了减少数据库的负担,提升数据库响应速度,缩短查询时间,这时候就需要进行 分库分表 。

2:什么是分库分表

分库分表就是要将大量数据分散到多个数据库中,使每个数据库中数据量小响应速度快,以此来提升数据库整体性能。核心理念就是对数据进行切分( Sharding ),以及切分后如何对数据的快速定位与整合。

针对数据切分类型,大致可以分为:垂直(纵向)切分和水平(横向)切分两种。

3:垂直拆分:根据业务逻辑拆分

垂直分库:安装业务垂直拆分数据库

垂直分表

优点

业务间解耦,不同业务的数据进行独立的维护、监控、扩展

在高并发场景下,一定程度上缓解了数据库的压力

缺点

提升了开发的复杂度,由于业务的隔离性,很多表无法直接访问,必须通过接口方式聚合数据,

分布式事务管理难度增加

数据库还是存在单表数据量过大的问题,并未根本上解决,需要配合水平切分

4:水平拆分:根据sharding规则拆分

 

库内分表

库内分表虽然将表拆分,但子表都还是在同一个数据库实例中,只是解决了单一表数据量过

大的问题,并没有将拆分后的表分布到不同机器的库上,还在竞争同一个物理机的CPU、内存、网络IO。

分库分表

分库分表则是将切分出来的子表,分散到不同的数据库中,从而使得单个表的数据量变小,

达到分布式的效果。

优点

解决高并发时单库数据量过大的问题,提升系统稳定性和负载能力

业务系统改造的工作量不是很大

缺点

跨分片的事务一致性难以保证 

跨库的join关联查询性能较差

扩容的难度和维护量较大

5:有哪些sharding规则

hash取模

优点

数据分片相对比较均匀,不易出现某个库并发访问的问题

这样同一个用户的数据都会存在同一个库里,用 userId 作为条件查询就很好定位了

缺点

但这种算法存在一些问题,当某一台机器宕机,本应该落在该数据库的请求就无法得到正确的

处理,这时宕掉的实例会被踢出集群,此时算法变成hash(userId) mod N-1,用户信息可能

就不再在同一个库中。

扩展性较差

取值范围,举例:根据年代

优点

单表数据量是可控的

水平扩展简单只需增加节点即可,无需对其他分片的数据进行迁移

能快速定位要查询的数据在哪个库

缺点

由于连续分片可能存在数据热点,如果按时间字段分片,有些分片存储最近时间段内的数据,

可能会被频繁的读写,而有些分片存储的历史数据,则很少被查询。

如果您觉得文章好看,欢迎点赞收藏加关注,一连三击呀,感谢!!☺☻

这篇关于【架构师面试-存储-6】-MySQL分库分表的拆分规则的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!