ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

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

2021-12-15 10:03:46  阅读:157  来源: 互联网

标签:分库 数据库 MySQL 切分 拆分 分片 分表 架构师


1:单节点MySQL的瓶颈在哪

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

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

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

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

2:什么是分库分表

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

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

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

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

垂直分表

优点

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

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

缺点

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

分布式事务管理难度增加

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

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

 

库内分表

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

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

分库分表

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

达到分布式的效果。

优点

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

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

缺点

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

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

扩容的难度和维护量较大

5:有哪些sharding规则

hash取模

优点

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

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

缺点

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

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

就不再在同一个库中。

扩展性较差

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

优点

单表数据量是可控的

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

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

缺点

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

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

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

标签:分库,数据库,MySQL,切分,拆分,分片,分表,架构师
来源: https://blog.csdn.net/chongfa2008/article/details/121929416

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有