10.4 数据库拆分（分布式)

发布于 2024-09-26 01:08:01 字数 4119 浏览 0 评论 0 收藏 0

垂直/水平拆分（分库分表）

首先进行垂直切分，按照表的内容将不同的表划分到不同的数据库中。（业务内容切分)

然后是水平切分，根据用户的 ID 将不同用户的内容再划分的不同的数据库中。

通过某种特定的条件，将存放在同一个数据库中的数据分散存放到多个数据库上，实现分布存储，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是 N 台服务器，这样就可以降低单台机器的负载压力。

垂直( 纵向) 拆分 ：是指按功能模块拆分，比如分为订单库、商品库、用户库…这种方式多个数据库之间的表结构不同。
水平（横向) 拆分：将同一个表的数据进行分块保存到不同的数据库中，这些数据库中的表结构完全相同。

图表结构不同的 垂直（纵向) 拆分 图

图表结构相同的水平（横向) 拆分图

垂直（纵向) 拆分

1， 实现原理 ：使用垂直拆分，主要要看应用类型是否合适这种拆分方式，如系统可以分为，订单系统，商品管理系统，用户管理系统业务系统比较明的，垂直拆分能很好的起到分散数据库压力的作用。

业务模块不明晰，耦合（表关联）度比较高的系统不适合使用这种拆分方式。但是垂直拆分方式并不能彻底解决所有压力问题，例如有一个 5000w 的订单表，操作起来订单库的压力仍然很大，如我们需要在这个表中增加（insert）一条新的数据，insert 完毕后，数据库会针对这张表重新建立索引，5000w 行数据建立索引的系统开销还是不容忽视的，反过来，假如我们将这个表分成 100 个 table 呢，从 table_001 一直到 table_100，5000w 行数据平均下来，每个子表里边就只有 50 万行数据，这时候我们向一张只有 50w 行数据的 table 中 insert 数据后建立索引的时间就会呈数量级的下降，极大了提高了 DB 的运行时效率，提高了 DB 的并发量，这种拆分就是横向拆分

2， 实现方法 ：垂直拆分方式实现起来比较简单，根据表名访问不同的数据库就可以了。

水平（横向) 拆分

(1) 顺序拆分 ：如可以按订单的日前按年份才分，2003 年的放在 db1 中，2004 年的 db2,以此类推。当然也可以按主键标准拆分。

优点：可部分迁移

缺点：数据分布不均，可能 2003 年的订单有 100W，2008 年的有 500W。

(2) hash 取模分 ：对 user_id 进行 hash（或者如果 user_id 是数值型的话直接使用 user_id 的值也可），然后用一个特定的数字，比如应用中需要将一个数据库切分成 4 个数据库的话，我们就用 4 这个数字对 user_id 的 hash 值进行取模运算，也就是 user_id%4 ,这样的话每次运算就有四种可能：结果为 1 的时候对应 DB1；结果为 2 的时候对应 DB2；结果为 3 的时候对应 DB3；结果为 0 的时候对应 DB4，这样一来就非常均匀的将数据分配到 4 个 DB 中。

优点：数据分布均匀

缺点：数据迁移的时候麻烦；不能按照机器性能分摊数据。

(3) 在认证库中保存数据库配置

就是建立一个 DB，这个 DB 单独保存 user_id 到 DB 的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以得到具体的 DB 信息，然后才能进行我们需要的查询操作。

优点：灵活性强，一对一关系

缺点：每次查询之前都要多一次查询，会造成一定的性能损失。

分库分表的主要问题

ACID 原则：保证数据一致性，如 Binlog（二进制日志）、
多表之间的关联查询
无法使用外键约束
无法使用全局 ID，如 Oracle 的 Sequence、MySQL 的 AUTO_INCREMENT 自增 ID。

Sharding 中间件

MySQL Cluster 和 MySQL Sharding

MySQL Cluster 是数据库集群，主要用于提升数据库的并行处理能力。
MySQL Sharding 是分片，不仅可以提升数据库的并行处理能力，还解决单表数据量大的问题。

表格 48 Sharding 中间件比较

功能	Cobar	MyCat	TDDL	Shark
是否开源	√	√	部分	√
架构模型	Proxy	Proxy	应用集成	应用集成
数据库支持	MySQL	任意	MySQL、Oracle	MySQL
外围依赖	无	无	Diamond	无
读写分离	√	√	√	√
分库分表	√	√	√	√