分库分表正在被淘汰

前言

"分库分表这种架构模式会逐步的被淘汰！" 不知道在哪儿看到的观点

如果我们现在在搭建新的业务架构，如果说你们未来的业务数据量会达到千万 或者上亿的级别 还在一股脑的使用分库分表的架构，那么你们的技术负责人真的就应该提前退休了🙈

如果对未来的业务非常有信心，单表的数据量能达到千万上亿的级别，请使用NewSQL 数据库 ，那么NewSQL 这么牛，分布库分表还有意义吗？

今天虽然写的是一篇博客，但是更多的是抱着和大家讨论的心态来的，所以大家目前有深度参与分库分表，或者NewSQL 的都可以在评论区讨论！

什么是NewSQL

NewSQL 是21世纪10年代初出现的一个术语，用来描述一类新型的关系型数据库管理系统（RDBMS）。它们的共同目标是：在保持传统关系型数据库（如Oracle、MySQL）的ACID事务和SQL模型优势的同时，获得与NoSQL系统类似的、弹性的水平扩展能力

NewSQL 的核心理念就是 将"分库分表"的复杂性从应用层下沉到数据库内核层，对上层应用呈现为一个单一的数据库入口，解决现在 分库分表的问题；

分库分表的问题

分库分表之后，会带来非常多的问题；比如需要跨库联查、跨库更新数据如何保证事务一致性等问题，下面就来详细看看分库分表都有那些问题

1. 数据库的操作变得复杂

   • 跨库 JOIN 几乎不可行：原本简单的多表关联查询，因为表被分散到不同库甚至不同机器上，变得异常困难。通常需要拆成多次查询，在应用层进行数据组装，代码复杂且性能低下。
   • 聚合查询效率低下 ：COUNT(), SUM(), GROUP BY, ORDER BY 等操作无法在数据库层面直接完成。需要在每个分片上执行，然后再进行合并。
   • 分页问题 ：LIMIT 20, 10 这样的分页查询会变得非常诡异。你需要从所有分片中获取前30条数据，然后在应用层排序后取第20-30条。页码越大，性能越差。

2. 设计上需要注意的问题

   • 分片键（Sharding Key）的选择：如果前期没有设计好，后期数据倾斜比较严重
   • 全局唯一ID需要提前统一设计，规范下来
   • 分布式事务问题，需要考虑使用哪种方式去实现（XA协议，柔性事务）

选择TiDB还是采用mysql 分库分表的设计

数据量非常大，需要满足OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 且预算充足 （分布式数据库的成本也是非常高的这一点非常的重要），并且是新业务新架构落地 优先推荐使用TiDB。 当然实际上选择肯定是需要多方面考虑的，大家有什么观点都可以在评论区讨论。

可以看看一个资深开发，深度参与TiDB项目，他对TiDB的一些看法：

1 什么是TiDB？

TiDB是PingCAP公司研发的开源分布式关系型数据库 ，采用存储计算分离架构 ，支持混合事务分析处理（HTAP） 。它与MySQL 5.7协议兼容，并支持MySQL生态，这意味着使用MySQL的应用程序可以几乎无需修改代码就能迁移到TiDB。

🚀目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

官方文档：docs.pingcap.com/zh/tidb/dev...

TiDB五大核心特性

TiDB之所以在分布式数据库领域脱颖而出，得益于其五大核心特性：

• 一键水平扩容或缩容：得益于存储计算分离的架构设计，可按需对计算、存储分别进行在线扩容或缩容，整个过程对应用透明。
• 金融级高可用：数据采用多副本存储，通过Multi-Raft协议同步事务日志，只有多数派写入成功事务才能提交，确保数据强一致性。
• 实时HTAP：提供行存储引擎TiKV和列存储引擎TiFlash，两者之间的数据保持强一致，解决了HTAP资源隔离问题。
• 云原生分布式数据库：通过TiDB Operator可在公有云、私有云、混合云中实现部署工具化、自动化。
• 兼容MySQL 5.7协议和生态：从MySQL迁移到TiDB无需或只需少量代码修改，极大降低了迁移成本。

2 TiDB与MySQL的核心差异

虽然TiDB兼容MySQL协议，但它们在架构设计和适用场景上存在根本差异。以下是它们的详细对比：

2.1 架构差异

表1：TiDB与MySQL架构对比

特性	MySQL	TiDB
架构模式	集中式架构	分布式架构
扩展性	垂直扩展，主从复制	水平扩展，存储计算分离
数据分片	需要分库分表	自动分片，无需sharding key
高可用机制	主从复制、MGR	Multi-Raft协议，多副本
存储引擎	InnoDB、MyISAM等	TiKV（行存）、TiFlash（列存）

2.2 性能表现对比

性能方面，TiDB与MySQL各有优势，主要取决于数据量和查询类型：

• 小数据量简单查询：在数据量百万级以下的情况下，MySQL的写入性能和点查点写通常优于TiDB。因为TiDB的分布式架构在少量数据时无法充分发挥优势，却要承担分布式事务的开销。
• 大数据量复杂查询：当数据量达到千万级以上，TiDB的性能优势开始显现。一张千万级别表关联查询，MySQL可能需要20秒，而TiDB+TiKV只需约5.57秒，使用TiFlash甚至可缩短到0.5秒。
• 高并发场景：MySQL性能随着并发增加会达到瓶颈然后下降，而TiDB性能基本随并发增加呈线性提升，节点资源不足时还可通过动态扩容提升性能。

2.3 扩展性与高可用对比

MySQL的主要扩展方式是一主多从架构，主节点无法横向扩展（除非接受分库分表），从节点扩容需要应用支持读写分离。而TiDB的存储和计算节点都可以独立扩容，支持最大512节点，集群容量可达PB级别。

高可用方面，MySQL使用增强半同步和MGR方案，但复制效率较低，主节点故障会影响业务处理[]。TiDB则通过Raft协议将数据打散分布，单机故障对集群影响小，能保证RTO（恢复时间目标）不超过30秒且RPO（恢复点目标）为0，真正实现金融级高可用。

2.4 SQL功能及兼容性

虽然TiDB高度兼容MySQL 5.7协议和生态，但仍有一些重要差异需要注意：

不支持的功能包括：

• 存储过程与函数
• 触发器
• 事件
• 自定义函数
• 全文索引（计划中）
• 空间类型函数和索引

有差异的功能包括：

• 自增ID的行为（TiDB推荐使用AUTO_RANDOM避免热点问题）
• 查询计划的解释结果
• 在线DDL能力（TiDB更强，不锁表支持DML并行操作）

3 如何选择：TiDB还是MySQL？

选择数据库时，应基于实际业务需求和技术要求做出决策。以下是具体的选型建议：

3.1 选择TiDB的场景

TiDB在以下场景中表现卓越：

1. 数据量大且增长迅速的OLTP场景 ：当单机MySQL容量或性能遇到瓶颈，且数据量达到TB级别时，TiDB的水平扩展能力能有效解决问题。
   例如，当业务数据量预计将超过TB级别，或并发连接数超过MySQL合理处理范围时。
2. 实时HTAP需求 ：需要同时进行在线事务处理和实时数据分析的场景。
   传统方案需要OLTP数据库+OLAP数据库+ETL工具，TiDB的HTAP能力可简化架构，降低成本和维护复杂度。
3. 金融级高可用要求 ：对系统可用性和数据一致性要求极高的金融行业场景。
   TiDB的多副本和自动故障转移机制能确保业务连续性和数据安全。
4. 多业务融合平台 ：需要将多个业务数据库整合的统一平台场景。
   TiDB的资源管控能力可以按照RU（Request Unit）大小控制资源总量，实现多业务资源隔离和错峰利用。
5. 频繁的DDL操作需求 ：需要频繁进行表结构变更的业务。
   TiDB的在线DDL能力在业务高峰期也能平稳执行，对大表结构变更尤其有效。

3.2 选择MySQL的场景

MySQL在以下情况下仍是更合适的选择：

1. 中小规模数据量 ：数据量在百万级以下，且未来增长可预测。
   在这种情况下，MySQL的性能可能更优，且总拥有成本更低。
2. 简单读写操作为主：业务以点查点写为主，没有复杂的联表查询或分析需求。
3. 需要特定MySQL功能：业务依赖存储过程、触发器、全文索引等TiDB不支持的功能。
4. 资源受限环境 ：硬件资源有限且没有分布式数据库管理经验的团队。
   MySQL的运维管理相对简单，学习曲线较平缓。

3.3 决策参考框架

为了更直观地帮助决策，可以参考以下决策表：

考虑因素	倾向TiDB	倾向MySQL
数据规模	TB级别或预计快速增长	GB级别，增长稳定
并发需求	高并发（数千连接以上）	低至中等并发
查询类型	复杂SQL，多表关联	简单点查点写
可用性要求	金融级（RTO<30s，RPO=0）	常规可用性要求
架构演进	微服务、云原生、HTAP	传统单体应用
运维能力	有分布式系统管理经验	传统DBA团队

4 迁移注意事项

如果决定从MySQL迁移到TiDB，需要注意以下关键点：

1. 功能兼容性验证：检查应用中是否使用了TiDB不支持的MySQL功能，如存储过程、触发器等。
2. 自增ID处理：将AUTO_INCREMENT改为AUTO_RANDOM以避免写热点问题。
3. 事务大小控制：注意TiDB对单个事务的大小限制（早期版本限制较严，4.0版本已提升到10GB）。
4. 迁移工具选择：使用TiDB官方工具如DM（Data Migration）进行数据迁移和同步。
5. 性能测试：迁移前务必进行充分的性能测试，特别是针对业务关键查询的测试。

5 总结

TiDB和MySQL是适用于不同场景的数据库解决方案，没有绝对的优劣之分。MySQL是优秀的单机数据库，适用于数据量小、架构简单的场景；数据量大了之后需要做分库分表。而TiDB作为分布式数据库，专注于解决大数据量、高并发、高可用性需求下的数据库瓶颈问题，但是成本也是非常的高

本人没有使用过NewSQL ，还望各位大佬批评指正