后端存储实战课
李玥
美团高级技术专家
44005 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
结束语 (1讲)
后端存储实战课
15
15
1.0x
00:00/00:00
登录|注册

15 | MySQL存储海量数据的最后一招:分库分表

灵活,可随时改变分片
查询友好,适合ToB系统
均匀分布数据和查询
分库解决高并发问题
分表解决查询慢问题
能不拆则不拆
提供金融级事务保证
讨论留言区
查表法
范围分片算法
哈希分片算法
分库分表为最后一招
限制数据库查询能力
根据业务访问数据方式选择
建议不考虑二次扩容问题
分库 vs. 分表
需要思考和解决多个问题
电商大厂在线交易业务仍需MySQL
MySQL本质是单机数据库
外键关联表处理
选择分片算法
选择Sharding Key
规划分库分表
分库分表实践困难
解决海量数据问题
分库分表

该思维导图由 AI 生成,仅供参考

你好,我是李玥。
从这节课开始,我们课程将进入最后一部分“海量数据篇”,这节课也是我们最后一节主要讲 MySQL 的课程。解决海量数据的问题,必须要用到分布式的存储集群,因为 MySQL 本质上是一个单机数据库,所以很多场景下不是太适合存 TB 级别以上的数据。
但是,绝大部分的电商大厂,它的在线交易这部分的业务,比如说,订单、支付相关的系统,还是舍弃不了 MySQL,原因是,只有 MySQL 这类关系型数据库,才能提供金融级的事务保证我们之前也讲过分布式事务,那些新的分布式数据库提供的所谓的分布式事务,多少都有点儿残血,目前还达不到这些交易类系统对数据一致性的要求。
那既然 MySQL 支持不了这么大的数据量,这么高的并发,还必须要用它,怎么解决这个问题呢?还是按照我上节课跟你说的思想,分片,也就是拆分数据。1TB 的数据,一个库撑不住,我把它拆成 100 个库,每个库就只有 10GB 的数据了,这不就可以了么?这种拆分就是所谓的 MySQL 分库分表。
不过,思路是这样没错,分库分表实践起来是非常不容易的,有很多问题需要去思考和解决。

如何规划分库分表?

还是拿咱们的“老熟人”订单表来举例子。首先需要思考的问题是,分库还是分表?分库呢,就是把数据拆分到不同的 MySQL 库中去,分表就是把数据拆分到同一个库的多张表里面。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

MySQL存储海量数据的挑战在于高并发和性能限制,而分库分表成为解决方案。在规划分库分表时,需考虑分库分表数量和选择Sharding Key,以满足查询需求。实施分库分表需谨慎,因其限制数据库查询能力,可能需将数据同步到其他存储系统。分库分表被视为解决数据量和并发问题的最后一招。常用的分片算法包括范围分片、哈希分片和查表法,各有优劣。对于订单表的分库分表,一般按用户ID作为Sharding Key,采用哈希分片算法。此外,分片相关知识适用于其他分布式数据库,原理通用。思考题则提出了关于外键关联表的处理。文章内容涵盖了分库分表的规划、实施和分片算法选择,对读者快速了解该主题具有指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《后端存储实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(49)

  • 最新
  • 精选
  • 李玥
    置顶
    Hi,我是李玥。 这里回顾一下上节课的思考题: 在数据持续增长的过程中,今天介绍的这种“归档历史订单”的数据拆分方法,和直接进行分库分表相比,比如说按照订单创建时间,自动拆分成每个月一张表,两种方法各有什么优点和缺点?欢迎你在留言区与我讨论。 这个问题我在本节课中也提到了,简单的总结一下。按月自动拆分订单的好处是,不需要做数据搬运,相对实现比较简单,数据分得更碎,缺点是跨月查询比较麻烦,但好处是容量也更大(因为分片更多)。归档历史订单的方法,实现起来更复杂,容量要小一些,但是对查询更加友好。
    2020-04-01
    25
  • leslie
    是不是漏了另外一种拆分方式:纵向拆分?分表应当还有一个原因,早期数据量小可以几十个字段都没有关系;后期数据量大了,多列查询导致了一些性能问题。我自己在生产中就碰到了设计的不合理性,做了纵向分表-效果还不错,精度只能靠实战、学习、反思去提升。 课程中提及的分表所引发的外键问题其实应当和DML有关:查询并无影响。个人觉得影响不大,细看是多张表,但是设计时其实还是一张;查询时对应的判断补进去就好。

    作者回复: 👍👍👍

    2020-04-02
    2
    37
  • 百威
    接“发条橙子”“用完整用户id分片还是后四位分片”对话:为什么是一样的啊,没懂……比如300个分片,用取模法,用户id分别为12000和22000,后四位相同但查找的表不同呀……我感觉这块没说清楚,我听完之后也有这个疑惑

    作者回复: 这个地方详细说一下,比如只取用户ID后四位,为了保证后四位的哈希结果和完整用户ID的哈希结果是一样的,分片的数量需要能被10000整除。300个分片是不行的,200、250这种分片数量就是可以满足要求的。

    2020-04-13
    7
    28
  • sami
    感觉Redis Cluster的分片规则有点像查表法

    作者回复: 你说的没错!

    2020-03-31
    24
  • Mq
    关联表可以冗余用户ID字段,跟订单表的都在一个库里吗,这样用户维度的交易都在一个库事物里面,大部分的关联查询也是在一个库里。 老师查找法有具体例子吗,我们之前也有过表按hash分后数据极度不均

    作者回复: 查表法一般可以配合哈希或者范围分片一起使用。 比如说,我们按用户ID哈希分成10个分片,其中第8个分片数据特别多不均匀。 那我们可以按用户ID哈希成100个逻辑分片。 再做一个100逻辑分片和10个物理分片的映射表,这个表里面只有100条记录。 那怎么来映射我们就可以人工分配,让10个物理分片中的数据尽量均匀。

    2020-03-31
    3
    16
  • Loren
    老师,请教一个问题,分库分表以后,数据量大的情况下,分页一般该怎么处理?我暂时没这方面的经验,想了解一下

    作者回复: 如果需要分库分表还要跨表查询,这种情况下没有什么好的分页解决方案,业务还是要规避分库分表之后跨表查询的情况。 如果实在规避不了,就要考虑sharding key是不是合理,或者可能要更换数据库。

    2020-04-04
    6
    13
  • 请问老师,假设现在是24个分片,使用取模算法,后续发现分片后数据量还是太大,要改成扩大分片数,需要重新迁移数据吧?工作量大且复杂,该怎么设计比较方便扩容呢

    作者回复: 比较方便的方法是扩容后的分片数量是24的整数倍,这样每个分片相当于1分n。或者在设计之初就采用一致性哈希算法来分片。

    2020-04-19
    11
  • 饭团
    老师您好,您提到的把用户id放到订单id中,是说如果用订单id去做查询,就把第10-14位取出来,之后再用这部分去查询是吗?

    作者回复: 是的

    2020-03-31
    17
    8
  • Echo
    老师您好:您文中说“范围分片特别适合那种数据量非常大,但并发访问量不大的 ToB 系统”,如果是这样的话 并发量不大的ToB 系统就没必要分库了吧?因为分库要解决的是高并发的问题。可以用分表或者归档的方式解决?

    作者回复: 是这样的。

    2020-05-16
    7
  • 曙光
    老师,我有个生产问题,内部管理系统,使用的是Oracle数据库,按月分表,该表每天新增近6W的数据,目前共有1亿的数据量。现在的问题是,业务每天都需要查这个表进行对账,查询速度很慢,每次慢的适合,我们就重建索引速度就快一点,过一段时间又会变慢。最要命的事,这些数据有一个归属人的字段,如果某个人换部门或离职,这部分历史数据都要归宿新人,涉及历史数据的修改。 之前通过归档历史表,处理查询慢的问题,发现还没重建索引收益高,就没修改了。但是交易归属人就比较麻烦,一次变更需要2~3分钟,体验很差。我目前想的解决方案是:重构历史功能,将交易表拆分成两张表,账户表,交易余额对账表和人员归属表,虽然每天6w笔数据,但大部分账户是一样的只是余额不一样。这样查询的话,每次需要关联3张表。如果真的这样实施,需要修改很多中间表的洗数流程。面对目前的数据量,我这种方案可行么?还有更好的修改方案么? 怕自己盲目修改后,和之前的查询修改性能差不多,就白忙活了

    作者回复: 如果一亿的数据分12个月,那实际上每个月的表中大概是一千万左右的数据,这个量级的数据,在做好索引的前提下,查询不会很慢。 建议你先看一下查询的执行计划,找出为什么慢的原因。 另外,你没有提到表中的数据是否会频繁删除。如果频繁插入和删除数据的这张表,它的索引会越来越大,定期重建索引是有必要的。

    2020-04-19
    6
    7
收起评论
显示
设置
留言
49
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部