一、前言

1. 企业 & 行业 & 业务介绍

我们是一家快速发展的金融科技公司，核心业务是为中小型金融机构提供在线信贷风控和交易处理平台。随着业务量的指数级增长，我们的系统每天需要处理数百万级的交易请求，并对海量的用户行为数据进行实时分析和查询。业务的强一致性、高可用性和快速迭代能力是我们技术选型的生命线。

2. 目前遇到的数据库挑战

在引入 TiDB 之前，我们的核心业务完全构建在 MySQL 之上，并采用了分库分表的架构。随着业务复杂度的提升，这一架构逐渐暴露出诸多痛点：

• 扩展性瓶颈： 分库分表后，业务逻辑变得异常复杂，DBA 团队需要投入大量精力进行数据路由和维护。水平扩展过程繁琐，无法应对业务的突发流量。
• 运维成本高： 在线 DDL 操作（如新增索引、修改字段）在亿级数据表上耗时极长，甚至导致业务停服，严重影响了产品的敏捷迭代。
• 高可用性风险： 虽然采用了主从复制，但主节点故障时的切换仍有数据不一致的风险，且手动切换的恢复时间（RTO）较长，不符合金融级业务要求。
• 存储成本压力： 业务数据量快速增长，MySQL 的原始存储方式使得磁盘成本成为一笔不小的开销，压缩比和存储效率有待优化。

3. 参加活动的原因

我们一直在寻找一个能同时满足 HTAP 混合负载、弹性扩缩容、金融级高可用且兼容 MySQL 协议的分布式数据库。平凯星辰推出的 TiDB 敏捷模式吸引了我们的注意，它宣称在保持 TiDB 核心优势的同时，提供了更轻量、更易部署和管理的体验。我们希望通过本次试用，验证其是否能解决我们当前面临的挑战，并为未来的核心系统架构升级提供技术选型依据。

4. 敏捷模式的体验总结

总体而言，TiDB 敏捷模式的试用体验非常顺畅。从部署、数据迁移到功能测试，整个流程都体现了“敏捷”二字。其高度兼容 MySQL 的特性极大降低了我们的学习和迁移成本，而内置的高可用和弹性扩展能力则让我们对替代传统分库分案充满了信心。

5. 敏捷模式是否能应对该挑战

答案是肯定的。 在后续的详细体验中，敏捷模式在在线 DDL、高可用、可扩展性和存储压缩方面均表现出色，直接命中了我们当前的痛点，展现出强大的潜力。

二、平凯数据库敏捷模式功能体验

1. 数据迁移体验，是否平滑

我们选择了从 MySQL 到 TiDB 敏捷模式的迁移路径。

• 工具选择： 我们使用了 TiDB 官方推荐的 DM (Data Migration) 工具。配置过程清晰明了。
• 体验： 迁移过程非常平滑。DM 工具能够稳定地同步全量数据和增量数据，在迁移过程中，源端 MySQL 库的业务仍在正常运行，最终实现了无缝割接，数据一致性得到了完美保障。平滑度令人满意。

2. MySQL 兼容性

兼容性是我们最为关心的一点。在试用中，我们发现：

• 绝大多数 SQL 语法、函数、数据类型均与 MySQL 兼容，我们的业务应用程序几乎无需修改即可连接到 TiDB 敏捷模式。
• 客户端驱动、ORM 框架（如 MyBatis, Hibernate）等也能正常工作。
• 极少数边缘特性或特定参数可能存在差异，但官方文档有详细的兼容性说明，帮助我们快速进行了适配。总体兼容性超过 95%，迁移成本极低。

3. 压缩比：降本增效实测

我们对比了相同数据量在 MySQL InnoDB 和 TiDB 敏捷模式（默认使用 RocksDB 引擎）下的磁盘占用。

• 测试方法：

  1. 在 TiDB 中导入约 100GB 的 MySQL 逻辑备份。
  2. 执行手动 Compact 操作（或等待系统自动触发），确保数据完成压缩。
  3. 使用 du -sh 命令分别查看 MySQL 数据目录和 TiKV 数据目录的大小。

• 测试结果：

  • MySQL 数据目录大小： ~100 GB
  • TiDB 敏捷模式数据目录大小： ~35 GB

• 结论： TiDB 敏捷模式展现了惊人的压缩能力，压缩比达到了约 65%，这意味着存储成本可以降低三分之二，降本增效成果显著。

4. 在线 DDL 操作易用性

我们针对常见的 schema 变更进行了测试：

• 增加/删除字段、修改默认值： 操作瞬间完成，对业务无感知，体验远超 MySQL。
• 创建索引： 在千万级大表上添加索引，TiDB 使用 ALGORITHM=INPLACE 方式，后台异步完成，整个过程不锁表，应用程序的读写操作完全不受影响。这与在 MySQL 大表上创建索引导致长时间锁表形成鲜明对比，极大地提升了开发效率。

5. 高可用/容灾（三节点）

我们模拟了故障场景来测试其高可用能力：

• 节点故障测试： 我们主动下线了一个 TiKV 节点。监控显示，集群在秒级内就感知到节点故障，并自动将故障节点上的数据副本调度到其他健康节点上。期间，整个集群的读写服务没有发生任何中断，仅部分请求有轻微延迟。故障节点恢复后，能自动重新加入集群并同步数据。
• 数据一致性验证： 在并发读写压力下，通过对比不同节点的数据，确认了数据的强一致性。
• RPO/RTO： 实测 RPO（数据恢复点目标）为 0，无数据丢失；RTO（恢复时间目标）在分钟级别，完全符合我们的预期。

6. 可扩展性

• 节点扩展： 我们体验了从三节点扩展的流程。通过 TEM 工具，添加新节点的操作简单，集群能够自动进行数据重平衡，扩展过程中业务无感知，真正实现了无缝水平扩展。
• 功能扩展： 我们额外部署了 TiCDC 组件，用于将实时数据变更同步到下游的数据仓库。TiCDC 的集成非常顺畅，对主集群性能影响微乎其微，展现了良好的生态扩展性。

7. 敏捷模式性能表现

通过 Sysbench 标准测试工具对比同等资源配置下的 TiDB 敏捷模式与 MySQL，结果显示：

• 读写混合场景： TiDB 敏捷模式性能与 MySQL 持平，部分场景下由于分布式事务的开销略有落后，但在可接受范围内。
• 纯读场景： 得益于其分布式架构，复杂查询的并发性能优于单机 MySQL。
• 结论： 性能表现完全满足我们当前业务场景的需求，且为未来的性能瓶颈提供了通过简单扩容即可解决的方案。

8. TEM 易用性

• 部署体验： 使用 TiDB Enterprise Manager (TEM) 部署敏捷模式集群异常简单。通过图形化界面，我们仅用了不到 30 分钟就完成了一个生产可用的三节点集群部署，包括监控告警体系的自动搭建。
• 多集群管控： TEM 的多集群管理功能非常强大。我们成功部署了多套环境（开发、测试、生产），并可以在统一的控制台上进行监控、巡检和日常运维操作，极大提升了运维效率。
• TEM 自身高可用： 我们按照指导部署了 TEM 的三节点高可用架构，建立了节点互信，确保了管理平台本身的稳定性。

三、平凯数据库敏捷模式优势 & 体验总结

1. 所在行业哪些场景会建议用敏捷模式

基于我们的试用体验，我们认为在金融科技、互联网、物联网等行业，以下场景特别适合使用 TiDB 敏捷模式：

• 快速增长的核心交易系统： 替代传统的分库分表，简化架构，应对未来不确定的数据量和访问量增长。
• 需要高可用保障的系统： 对业务连续性要求高的场景，敏捷模式内置的金融级高可用能力是巨大优势。
• 需要频繁进行 schema 变更的敏捷开发业务： 在线 DDL 能力能极大释放开发团队的生产力。
• 对存储成本敏感的海量数据业务： 出色的压缩比能直接带来可观的成本节约。

2. 敏捷模式整体体验总结

本次对平凯数据库敏捷模式的试用给我们留下了深刻的印象。它成功地将分布式数据库的强大能力与轻量敏捷的部署运维体验结合在一起。其核心价值在于：

• “省心”： 高可用、弹性扩展等复杂能力开箱即用，减轻了 DBA 的运维负担。
• “省钱”： 极高的数据压缩比直接降低了存储成本。
• “敏捷”： 优秀的 MySQL 兼容性和无锁 DDL 特性，保障了业务开发的敏捷性。

我们计划将部分新业务模块率先部署在 TiDB 敏捷模式上，并逐步将核心业务从复杂的 MySQL 分库分表架构迁移过来。它无疑是我们应对未来业务挑战的理想数据库解决方案。