" name="sm-site-verification"/>
侧边栏壁纸
博主头像
PySuper博主等级

千里之行,始于足下

  • 累计撰写 203 篇文章
  • 累计创建 14 个标签
  • 累计收到 1 条评论

目 录CONTENT

文章目录
SQL

MySQL 数据库拆分

PySuper
2021-06-25 / 0 评论 / 0 点赞 / 16 阅读 / 3085 字
温馨提示:
所有牛逼的人都有一段苦逼的岁月。 但是你只要像SB一样去坚持,终将牛逼!!! ✊✊✊

单体项目在构建之初,数据库的负载和数据量都不大,所以不需要对数据库做拆分。

小型财务系统、文书系统、ERP 系统、OA 系统,用一个 MySQL 数据库实例基本就够用了。

但是随着数据量的飞速增长,一个MySQL的实例已经不够用了。

随之而来的就到了数据库的优化:分库分表、分布式… …

水平拆分

一条记录一条记录切断分出来

MySQL水平拆分
  • 优点
    • 表关联基本能够在数据库端全部完成
    • 不会存在某些超大型数据量和高负载的表遇到瓶颈的问题
    • 应用程序端整体架构改动相对较少
    • 事物处理相对简单
    • 只要切分规则能定义好,基本上较难遇到扩展性限制
  • 缺点
    • 切分规则相对更为复杂,很难抽象出一个能满足整个数据库的切分规则
    • 后期数据的维护难度有所增加,人为手工定位数据更为困难
    • 应用系统各模块耦合度较高,可能会对后面数据的迁移拆分造成一定的困难

垂直拆分

把常用的,不常用的,字段很长的拆出来

MySQL垂直拆分
- 拆分规则 - 把不常用的字段单独放在一个表 - 把 text,blob 等大字段拆分出来放在附表中 - 经常组合查询的列放在一张表中 - 优点 - 数据库的拆分简单明了,拆分规则明确 - 应用程序模块清晰明确,整合容易 - 数据维护方便易行,容易定位 - 缺点 - 部分表关联无法再数据库级别完成,需要在程序中完成 - 对于访问极其频繁且数据量超大的表仍然存在性能瓶颈,不一定满足需求 - 事务处理相对更为复杂 - 切分达到一定程度后。扩展性会遇到限制 - 过度切分可能会带来系统过度复杂而难以维护

拆分顺序

1、数据分片

  • 随着数据量的增加,首先做数据分片
    • 利用多块硬盘来增大数据 IO 能力和存储空间,这么做的成本是最低的
    • 几块硬盘的钱就能收获不错的 IO 性能。

2、水平拆分

  • 数据量继续增大,把数据切分到多个 MySQL 节点上,用 MyCat 管理数据切分
  • 处理MySQL的读写分离
  • 在做水平拆分的同时,业务系统可以引入负载均衡、分布式架构等
  • 理论上,冷热数据分离之后,水平拆分可以维持蛮久的,做好定期归档就好了

3、垂直拆分

  • 数据库到了水平切分的阶段,数据量的增加已经不是更改架构设计的主要原因了
  • 反而是业务系统承受不住了,所以按照模块和业务,把一个系统拆分成若干子系统
  • 若干子系统之间,数据相对独立 ==> 垂直切分,把数据表归类,拆分成若干个数据库系统。

如果过早的对数据库做了垂直切分,势必要重新构建若干独立的业务系统,工作量太巨大

水平切分并不需要业务系统做大幅度的修改,因此说应该先从水平切分开始做

0
SQL
  1. 支付宝打赏

    qrcode alipay
  2. 微信打赏

    qrcode weixin

评论区