架构师必看！现代应用架构发展趋势与数据库选型建议丨TiDB vs MySQL 专题（一）

导读

在当今数智化飞速发展的时代，现代应用架构正经历着一场深刻的变革。云原生、微服务、大数据等新兴技术与架构模式不断涌现，推动着应用向更高效、更灵活、更智能的方向演进。然而，数据量的爆发式增长、并发访问的急剧增加、多租户与混合负载的需求，以及企业对智能化运维和数据安全性的更高期望，都使得数据库在性能、扩展性、可靠性等方面面临严峻考验。 TiDB 作为分布式数据库，在高扩展性、高可用性、性能卓越等方面为现代应用架构提供了全新的解决方案。

本文将深入探讨现代应用架构的发展趋势，分析数据库的挑战与需求，并为架构师们提供数据库的选型建议，助力企业在数字化浪潮中稳健前行。

本文作者：蓝功儒 & 李仲舒 & 童童

---

现代应用架构的技术演变趋势：从 LAMP 到分布式智能化

随着互联网、移动互联网、AI 等技术的大爆发背景下，现代企业主要面临六大挑战：AI 驱动下数据量的爆炸性增长；对高并发和高吞吐需求的应对；高可用以及业务连续性保障；多租户和资源隔离能力实现降本增效；IT 架构向云方向的演进以及与云基础设施的无缝集成；现代应用架构下诸多技术挑战等。

现代应用架构在业务需求与技术进步双轮驱动下，依托于开源技术，经历了高速的发展，成熟度也在不断提升。回顾往昔，Linux、Apache、MySQL 以及 PHP 的简单组合（LAMP）曾是搭建应用网站的主流框架。而随着互联网、移动互联网用户规模的几何级膨胀、业务场景的复杂化，以及企业对系统性能、扩展性、稳定性要求的不断提高，传统的 LAMP 架构逐渐暴露出诸多瓶颈。为突破这些限制，无论是应用还是数据库都向着分布式的大方向演进。整体来看，现代应用技术整体向 分布式化、技术精细化、功能模块化、智能化、可视化、需求多样化 等方向演进。

现代应用架构下数据库演变趋势

数据库经过近 60 年的发展历程看，1980 年代的大型机占主导，关系型模型与 SQL 成为主流。1990 年代，随着互联网的快速发展，小型机兴起，开源数据库逐步兴起。2000 年代，互联网技术的推动下，数据量暴增，虚拟化技术、分布式崛起。2010 年代，移动互联网让联网人数又有了指数级的增长，驱动了大数据与云技术的发展，在此背景下，应用以及数据库又朝着云原生方向进一步发展。2020 年代，实时数据分析以及 AI 需求驱动下，应用以及数据库又有了进一步的迭代发展。

从全球数据库技术的发展趋势中，我们可以看到几个关键要素：

1. 数据库技术不断进步，进入多元化发展阶段

2. 分布式和云原生重新塑造数据库形态

3. 数据库技术与大数据应用深度融合发展

4. 存算分离已成为数据库发展的主流方向

5. HTAP 成为新的关注方向

天下合久必分，分久必合。从数据库发展趋势中，我们看到 原生分布式已经是数据库发展的主流方向、是新质生产力的代表、是防止技术断代的核心技术。分库分表模式是过渡性技术，集中式数据库会越来越边缘化 。我们也可以预测，数据库的技术栈将逐渐收敛，以此为企业提供扎实的数据底座、敏捷的开发体验、极简的技术栈，帮助企业应对现代企业的六大挑战。

MySQL 演变趋势

MySQL 的发展起步于 3.23 版本，当时崭露头角，以 MyISAM 作为存储引擎，完善了基础 SQL 功能，并支持多用户多线程处理。到了 4.0 版本，引入 InnoDB 引擎，构建起关系型事务模型，同时增加了存储过程和触发器等功能。5.7 版本则标志着 MySQL 迈向企业级应用，存储引擎变得可插拔，具备外键约束、主从复制以及分区表等特性。8.1 版本进一步提升，达到金融级标准，增强了安全性、数据分析能力、Cluster 能力和资源控制。最新的 9.1 版本构建起现代架构，引入 Vector 数据类型，更加面向云原生，并增强了可观测性。

我们可以看到，MySQL 产品及生态近几年主要是围绕着 云原生、HTAP、高可用、AI、可观测性、Resource Control、安全性 等方面进行迭代演进。

• 数据量承载： 早期，MySQL 主要以单体机架构运行，适用于 GB 级别的数据量。随着业务发展，数据量增长，开始采用分库分表的方式承载 PB 级数据。但这种方式带来了业务和运维的高复杂度，因此，许多企业选择切换到 TiDB 这种原生分布式数据库，它能在保证性能的同时，更便捷地处理大规模数据。
• 云原生部署： MySQL 最初以单体机架构部署，后来发展到 RDS（关系型数据库服务）。随后，出现了以 Auraro、PolarDB 为代表的基于共享分布式存储的云原生架构。然而，这些架构在吞吐扩展和数据承载能力上存在局限。为满足更高需求，用户逐渐转向 TiDB Cloud，它们具备更强大的云原生能力，能更好地适应复杂多变的云计算环境。

现代应用架构下 MySQL 体系面临的七大挑战

1. 数据强一致： 读写分离架构或者分库分表架构的引入，数据的强一致性保障成为重点关注问题，保证强一致性便需极大的牺牲性能，这是 MySQL 体系一直以来困扰诸多 MySQL 使用者的问题。

2. 业务无侵入： 随着业务系统数据量的增长，早起只能无奈采取分库分表方案以及架构，这不单为运维带 来了极高的复杂度，同时对业务开发也带来的极大的入侵，SQL 只能限定按照 shard key 维度进行编写，无法任意维度的进行 SQL 查询，开发不得不牺牲业务需求，业务的发展也不得不受限，同时又需投入大量的高精尖人才进行开发维护。

3. TB～PB 级别数据承载能力： 随着互联网、移动互联网、AI 的爆发，各个企业的业务系统数据量都在向着 TB 级别、百 TB 级别，甚至我们发现也有很多用户数量在向着 PB 级别增长。这对数据库的承载能力提出了极高的挑战，不但需要承载大数据量，又需要保障业务读写性能的稳定性，而在数据的承载能力上，MySQL 的极限，是 TiDB 的起点。

4. 高吞吐能力 & 多点读写能力： 对于数据库多点读写是一个稀缺的能力，而基于 MySQL 二次开发的生态下的产品很难实现业务无侵入的需求下数据库的多点读写能力，以适应高吞吐场景。

5. 高可用： 尽管 MySQL 提供了多种高可用架构（如主从复制、主主复制、MHA、InnoDB Cluster 等），但这些方案仍存在一些不足，如配置复杂、运维困难、性能损耗、一致性保障困难等。

6. 横向扩展能力： MySQL 的读写分离架构提供了弱一致性读能力的扩展，分库分表架构必须成倍的扩容且需要业务停机，数据重分布又极其复杂，这对架构师、DBA、开发者都提供了极大的复杂度和挑战。

7. 复杂 SQL 查询能力强： MySQL 的复杂查询能力一直被大家所诟病，在 MySQL 的版本迭代中，我们也可以看到一直在做优化器的增强，提升 MySQL 对复杂 SQL 的处理能力，但相对 Oracle，目前仍存在一定差距。

现代应用架构新选择：原生分布式数据库，一键解决七大挑战

与传统的 MySQL 架构相比，原生分布式数据库凭借完全分布式架构、数据透明分布、原生高可用、数据强一致、HTAP 等能力特点，极大简化读写分离和分库分表的复杂度，减少了中间件的使用，大幅降低运维复杂性并提高了系统的稳定性和性能；具备为现代应用架构提供一个强大、灵活、高效、敏捷的数据底座能力。

原生分布式数据库一站式应对：

1. 数据强一致： 原生分布式数据库采用多数派协议，默认的三副本配置，数据强一致同步，彻底的解决了数据强一致性的问题。

2. 业务无侵入： 在原生分布式数据库中，业务开发者完全回归 MySQL 单机开发体验，数据可以任意维度分析，无需牺牲任何也许需求或引入更多技术栈。

3. TB～PB 级别数据承载能力： 原生数据库凭借着细粒度的数据存储单位，强大的数据管理及调度能力，充分利用大数据下多点计算的能力，具备支撑PB级别数据量承载以及业务稳定性保障能力。

4. 高吞吐能力 & 多点读写能力： 对于数据库多点读写是一个稀缺的能力，采用存算分离的原生分布式数据库以更小的单位为存储单位，可充分发挥数据库多点读写能力，以适应高吞吐场景。尤其在 DTC 场景，如互联网、零售、公共事业这类直接面向最终用户的场景下，原生分布式数据库可以充分利用分布式的多点写入能力来满足业务极高吞吐的要求。

5. 高可用： 原生分布式数据库采用的多数派协议，原生具备故障自愈、故障转移、数据副本自动补充等能力，对用户提供了更友好更可靠的高可用能力。

6. 横向扩展能力： 原生分布式数据库可按需针对计算或存储去扩容，且可随意数量的扩展，比如一次只扩展一个 8c16G 配置的存储实例。一行命令完成扩展，无需任何的人工干预。

7. 复杂 SQL 查询能力强： 原生分布式数据库充分利用分布式的架构以及能力，将行列双引擎物理隔离，列引擎具备 MPP 计算能力，让数据库拥有了接近传统 OLAP 数据库的复杂 SQL 处理效率和能力。

现代应用架构的数据库选型建议

（一）企业实力

1. 代码自主可控率： 核心自主可控率，生态工具自主可控率，是否能真正掌握产品核心代码

2. 企业资本规模： 企业的资产规模，企业的背景

3. 研发力量投入： 研发实力，数据库产品投入力度

4. 原厂工程师数量： 原厂售前售后工程师数量

（二）市场认可

1. 产品下载量、装机量、市场关注度

2. 同业案例： 同业核心系统案例数量，市场认可度

3. 同业调研： 同业一般系统案例数量，同业调研认可度

4. 三方评估： 权威的评估机构，中立的第三方评估网站

5. 在行业内横向对比情况做参考

（三）生态环境

1. 工具完善性： 监控巡检工具的关键指标完善性，数据迁移工具、数据同步工具支持情况

2. 文档完善性： 官方文档准确性、完普性，问题知识库的完备性

3. 认证完善性： 培训体系的完整性，获得证书人员的数量

4. 软硬件兼容性： 支 持国产操作系统数量，支持国产芯片服务器数量

5. 备份恢复的便捷性，安装部署的方便性

6. 社区支持： 是否自己构建开源社区，是否与国内外开源社区合作

7. 社区活跃度： 社区注册人数，企业数量等

（四）产品实力

1. 架构先进性： 可靠性、可用性、可横向扩展性、云原生，多地多中心架构支持情况

2. 语法兼容性： 兼容 MySQL、PostgreSQL、Oracle 语法其中一种或多种语法

3. 采购维保成本： 软件 License 成本，每年维保服务成本相同架构基础设施成本

4. 性能： 选定业务系统进行 QPS/TPS 对比、横向扩展性的性能提升

5. 产品生命力： 产品是否具备不断迭代提升能力，产品成长能力是否足够，是否具备长期做好一款数据库的决心和实力

TiDB：原生分布式+强 MySQL 兼容，轻松解决应用架构难题

存算分离的云原生架构，用户投票的结果

TiDB 在架构上选择存算分离的云原生架构，对开发者提供了极致的敏捷开发体验，对业务提供了多点读写能力应对高吞吐场景，采用多数派协议默认三副本配置，原生的具备高可用以及故障自动转移能力。同时，采用业界领先的行列双引擎物理隔离的 HTAP 架构，为用户的实时数据分析简化架构，提升实时性。其实，TiDB 的整体架构演变是基于用户需求投票出来的结果。

那么，TiDB 对于现代企业具备什么价值呢？企业利用 TiDB 的横向扩展联机能力能应对绝大多数联机业务场景，再借助 TiDB 的列存引擎以及大数据库计算引擎的能力，应对大数据实时以及离线的数据分析需求。可极大的简化技术栈，提升敏捷开发体验，为企业诸多业务提供扎实的数据底座。彻底摆脱数据强一致性、业务侵入、扩展能力、高可用、数据分析等常面临的挑战。

强 MySQL 生态兼容，实现低成本迁移

TiDB 提供了强 MySQL 生态。无论是开发语言、ORM、连接池，客户端工具，基本都保持强兼容。同时也提供了最高效的数据导出导入、备份恢复工具，进一步加强了 TiDB 的生态。另一方面，TiDB 和常见的国产操作系统、CPU 芯片都是 100% 兼容，且有生产案例。

了解更多数据库选型资料

<center>TiDB vs MySQL Meetup 第一期 PPT 下载</center>