分库分表真的适合你的系统吗？聊聊分库分表和NewSQL如何选择

绝地灬酷狼 2023-09-28 14:42 6阅读 0赞

![format_png][]

曾几何时，“并发高就分库，数据大就分表”已经成了处理 MySQL 数据增长问题的圣经。

面试官喜欢问，博主喜欢写，候选人也喜欢背，似乎已经形成了一个闭环。

但你有没有思考过，*分库分表真的适合你的系统吗？*

### 分表 ###

在业务刚刚发展起来的时候，流量全部打到了一个 MySQL 上，用户信息全落到了 user 表。

![format_png 1][]

后来，user 表的数据量越来越大了。

于是，你做了一次垂直拆分，将原来的 user 表拆分成了新的 user 表和 user\_details 表。

![format_png 2][]

这样一拆之后，用户的信息分散到两个表，user 表的数据量一下就变小了，user 表数据量过大的问题暂时就解决了。

但随着业务的发展，线上的流量越来越大，单个 MySQL 已经扛不住流量的压力了。

![format_png 3][]

单个库承受不住压力的时候，就需要分库了。

### 分库 ###

顾名思义，分库就是将一个库拆成多个库，让多个库分担流量的压力。

拆成多个库也意味着进行了分表，也就是说分库一定分表，分表不一定分库。

我们可以根据\_偏应用\_还是\_偏 DB\_，将分库分表的实现方式分成三种类型：

*  JDBC 代理模式
 *  DB 代理模式
 *  Sharding On MySQL 的 DB 模式

#### JDBC 代理模式 ####

JDBC 代理模式是一种无中心化的架构模式。ShardingSphere-JDBC 就是 JDBC 代理模式的典型实现。

通常以 jar 包形式提供服务，让客户端直连数据库，这种模式无需额外部署和依赖，可理解为增强版的 JDBC 驱动。

![format_png 4][]

JDBC 代理模式虽然简单，但违背了 DB 透明的原则，侵入性比较高，需要针对不同的语言编写不同的 Driver。

美团的 Zebra、MTDDL，阿里 TDDL 都是基于这种模式的实现。

#### DB 代理模式 ####

DB 代理模式是中心化的架构模式。ShardingSphere-Proxy 就是 DB 代理模式的经典实现。

这种模式旨在实现透明化的数据库代理端，并独立于应用部署，因为独立部署，所以对异构语言没有限制，不会对应用造成侵入。

![format_png 5][]

DB 代理模式比 JDBC 代理模式消耗的连接数会少，相对来说性能也会更好。

但中心化的设计也带来了单点的问题，为了保持高可用和高性能，还需要引入 LVS/F5 等 VIP 来实现流量的负载均衡，如果跨 IDC，还依赖诸如 DNS 进行 IDC 分发，大大拉长了应用到数据库的链路，进而提高了响应时间。

阿里的 MyCat、美团的 Meituan Atlas 和百度 Heisenberg 就是基于 DB 代理模式的实现。

#### Sharding On MySQL ####

Sharding On MySQL 相当于屏蔽了分库分表的操作，是运维和中间件结合的沉淀，比较典型例子是阿里的 DRDS。

![format_png 6][]

这种模式让分库分表变得模糊，对应用来说，更像是一个封装了 MySQL 的新型数据库。

虽然用户使用变得更简单了，但简单的背后是运维的沉淀，分库分表该存在的问题它依然存在。

### 分库分表的成本 ###

实现分库分表的方式有很多，但不同模式的实现似乎都是在弥补 MySQL 不支持分布式的缺陷。

分库分表这种强行让 MySQL 达到一个伪“分布式”的状态，也带来了一些新的问题，比如：

1.  **功能限制问题**：分库分表后跨维度 join、聚合、子查询不复存在，唯一键、外键等全局约束也只能靠业务保障，DB 慢慢弱化为存储。
2.  **运维复杂度问题**：分库分表后的多个库表的管理麻烦，运维成本非常高，数据查询也很麻烦。
3.  **Sharding Key 问题**：非 Sharding key 的查询需要做额外的冗余处理，需要引入 Elasticsearch、ClickHouse 等其他节点，进一步提高了系统的复杂度。
4.  **唯一 ID 问题**：分库分表后唯一 ID 得不到保障，需要对唯一 ID 进行改造。
5.  **分布式事务问题**：MySQL 自带的 XA 柔性事务性能太低，需要引入新的分布式事务解决方案。

### NewSQL ###

从上文得知，分库分表需要牺牲 MySQL 的一些功能，还带来许多新的问题。

那有没有一种方案，既能拥有 MySQL 的功能，又能支持数据的可扩展？

有。那就是 NewSQL。

NewSQL 是一类关系数据库管理系统，旨在为在线事务处理(OLTP) 工作负载提供 NoSQL 系统的可扩展性，同时保持传统数据库系统的 ACID 保证。

国内比较知名的 NewSQL 有阿里的 OceanBase、腾讯的 TDSQL、PingCAP 的 TiDB。它们既有 MySQL 的功能，又有分布式可扩展的能力。

笔者对阿里的 OceanBase 只能说是略懂皮毛，就不过多描述。

我们重点看一下腾讯的 TDSQL 和 PingCAP 的 TiDB。

![format_png 7][]

从两者的架构图（省略了部分模块）上可以看出，TDSQL 和 TiDB 的架构只有一些命名差别，可以说几乎一模一样。

两者整体来说分为三个部分：

1.  **计算**：负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划转发给底层的存储层执行。（TDSQL：SQL Engine 、TiDB：TiDB-Server）
2.  **存储**：分布式\_KV 存储\_，类似 NoSQL 数据库，支持弹性扩容和缩容。（TDSQL：TDStore 、TiDB：TiKV）
3.  **管控**：整个集群的元信息管理模块，是整个集群的大脑。（TDSQL：TDMetaCluster 、TiDB：Placement Driver ）

两者核心的存储模块（TDStore/TiKV），都是基于 RocksDB 开发而来，都是\_KV 存储\_的模式。

> RocksDB 是由 Facebook 基于 LevelDB 开发的一款提供键值存储与读写功能的 LSM-tree 架构引擎。
> 
> 底层利用了\_WAL(Write Ahead Log)技术\_和\_Sorted String Table\_，比 B 树类存储引擎更高的写吞吐。

### NewSQL 平滑接入方案 ###

因为笔者落地过 TiDB，所以会以 TiDB 为例描述如何接入 NewSQL，做到不影响线上使用的平滑迁移。

![format_png 8][]

**第一步**：初始状态，所有线上读和写都落到 MySQL。

**第二步**：将 TiDB 作为 MySQL 的从节点接入系统，所有线上读写还是都落到 MySQL，日末通过脚本或者任务验证 MySQL 的数据和 TiDB 的数据是否一致，这一步主要验证 MySQL 数据同步到 TiDB 没有问题。

**第三步**：将部分读切换到 TiDB，这一步主要验证 TiDB 同步的数据读没有问题，验证系统 SQL 能正常在 TiDB 执行。

**第四步**：断掉 MySQL 和 TiDB 之间的同步，双写 MySQL 和 TiDB，所有的线上读流量都落到 MySQL。

**第五步**：将部分读流量切到 TiDB，验证 TiDB 写入的数据能够正常读取。这一阶段可以将部分幂等任务同时在两个数据源上执行，验证两者数据是否一致。

**第六步**：将所有的线上读流量切到 TiDB，同时保持双写，如果出问题随即切到 MySQL。

**第七步**：断掉 MySQL 的写流量，将 MySQL 作为 TiDB 的一个从库，作为降级使用。

整个方案的基础是：**TiDB 兼容 MySQL 协议和 MySQL 生态**。

这个方案是建立在**完全不信任 TiDB**的基础上设计的，验证了 TiDB 和 MySQL 的契合点，所以整体会比较繁琐，实际落地的时候可以根据情况省略一部分步骤。

### NewSQL 真的有那么好吗？ ###

NewSQL 并是不万能的，也不必去过于神化 NewSQL，国内比较知名的几种 NewSQL 或多或少都存在部分功能缺陷，以 TiDB 为例：

1.  TiDB 的自增 ID 只能保证单个 TiKV 上的自增，并不能保证全局自增。
2.  由于 TiKV 存储是根据 key 的二进制顺序排列的，使用自增 ID 可能会造成热块效应。
3.  TiDB 默认 RC（读已提交）的事务隔离级别，并且不支持 RR（可重复读）隔离级别，虽然提供了基本等价于RR的SI（Snapshot Isolation），但还是存在\_写偏斜\_问题
4.  TiDB 的点查（select point）性能比 MySQL 要差不少，在几个亿级别的数据量才能勉强和 MySQL 打平。
5.  因为底层基于 Raft 协议做数据同步，所以 TiDB 延迟会比 MySQL 要高。
6.  ...

所以说，NewSQL 也并不是屠龙刀，需要根据实际应用去评估这些缺陷带来的影响。

### NewSQL 的应用 ###

NewSQL 在国内其实已经发展了很多年，OceanBase 诞生于 2010 年，TDSQL 可追溯到 2004 年，TiDB 诞生于 2015 年。

三者在国内外积累了不少的客户案例。

#### OceanBase ####

1.  OceanBase 已经覆盖**蚂蚁集团**100%核心链路，支撑全部五大业务板块。目前运行数十亿条不同的 SQL、数据量达数百 PB、服务器核数过百万。
2.  **中国工商银行**全行业务都使用 OceanBase，包含不限于存、贷、支付结算及创新业务等。
3.  OceanBase 凭借混合云架构、高可用、Oracle 兼容等特性，通过分布式中间件、金融套件、移动开发平台集成解决方案，支撑**网商银行**核心系统数字化转型。
4.  **招商银行**的“海量行情系统”和“历史收益系统”就是采用 OceanBase 作为底层数据库。

#### TDSQL ####

1.  **微众银行**实现了 TDSQL 私有化部署，是一个典型的两地多中心架构。
2.  **富途证券**的港股交易系统、东吴证券新一代核心交易系统底层存储都是 TDSQL。
3.  数字广东**粤省事**、**深圳地铁码上乘车**等业务都是在 TDSQL 上面跑的。
4.  **平安银行、中国农业银行、华夏银行、中国银行**都有相关业务在 TDSQL 上。

#### TiDB ####

1.  **北京银行**的网联支付业务，所有北京银行的银行卡绑定在比如支付宝、微信上的支付操作，后端的数据库就是运行在 TiDB，而且是一个典型的两地三中心同城双活的架构，这个业务非常的关键，如果业务中断超过一定时间，就是需要上报银监会的。
2.  日本排名第一的支付公司——**Paypay**，钱包和支付的业务都在 TiDB 上面。
3.  **中国人寿**的寿财险业务，正在用 TiDB 陆续替换 Oracle 。
4.  **肯德基**所有的会员登录系统，包括 KFC 的 APP 以及第三方登录，后台数据库都是用的 TiDB ，这套业务 2020 年 4 月份上线，已经经历过多次肯德基的大促等活动，目前肯德基的后台支付系统也已经切换到 TiDB 上。
5.  **麦当劳**的账户以及订单系统全部基于 TiDB，如果 TiDB 出问题了，那么国内所有的麦当劳门店，包括线上和线下的点单系统都将没法正常运行。
6.  **微众银行**最核心和最赚钱的微粒贷业务，后台的全量批处理业务就运行在 TiDB 上面。

### 分库分表和 NewSQL 到底怎么选？ ###

分库分表是一个重量级的方案，它会带来很多新的问题，对基建和运维的要求也很高。

NewSQL 功能强大但也有功能缺陷。

如何去抉择需要根据系统现状和公司情况去综合判断。

![format_png 9][]

分库分表是一个重量级的方案，如果\_读写分离\_、*冷热分离\_等轻量级方案能解决的问题就没必要上\_分库分表*。

如果缓存分流和读写分离都扛不住了，且你身处互联网企业，基建尚可且运维也跟得上，\_分库分表\_仍然是第一选择；

但如果你身处一个传统的企业，基建很差甚至没有基建，那么你可以考虑考虑\_NewSQL\_。

![a15731c019eb4a999038ebb00f0ed6f5.jpeg][]

[format_png]: https://img-blog.csdnimg.cn/img_convert/df49f59651c539abe72e0d26d8a90c00.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/fc4ada0b05e44cebfa3fe880b488182f.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/9d5a8967bdd70a05c76a721bec848223.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/a9c46c6293e2b283d043df5331ffb6f8.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/04dde1728c052b1d4b04de53df004e97.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/8bf271cbd719cc229a10e09044389c32.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/bce9994212c6b303e6185d55dd0df3a4.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/7a42ccd637543cf3ba824150cbaac26e.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/af82f7cd85d6df75b115b9c1fa84e5c8.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/463c46fbb5274521a9efc4a19385d474.webp?x-oss-process=image/format,png
[a15731c019eb4a999038ebb00f0ed6f5.jpeg]: https://img-blog.csdnimg.cn/a15731c019eb4a999038ebb00f0ed6f5.jpeg