业务挑战
- 聚合库瓶颈： 随着数据量增长，后端用于报表分析的 Oracle 聚合库面临单机存储容量上限，且部分 SQL 查询效率越来越差，分析时效性持续下降。
- 业务需求受限： 为保障查询时效性，不得不减少 Oracle 中的数据存储周期，但这反过来导致了部分依赖长期数据的业务需求无法实现。
- 分库架构复杂： 前端 MySQL 分库分表（MyCAT）规则基于静态策略，在组织机构合并或新增业务时，需要大量人工调整策略和手动导数据，扩容和维护困难。
- 同步维护成本高： 业务高度依赖 Otter 将数据从 MySQL 实时汇聚到 Oracle，上百个同步通道维护成本巨大，且易因源端 DDL 或大表 DML 操作导致同步延迟或中断。
解决方案
云盛海宏调研 PG XL、kudu+Impala、TiDB 后，选择 TiDB 作为核心解决方案，具体落地如下：
- 替换 Oracle 承担聚合库职能：引入 TiDB 与 Oracle 共同支撑聚合库需求，后续将绝大部分功能迁移至 TiDB；依托 TiDB 分布式架构，解决存储容量上限问题，支持数据存储周期延长，满足此前无法实现的业务需求。
- 适配现有技术栈降低改造成本：TiDB 兼容 MySQL 协议，现有业务无需过多改造即可迁移；复杂 SQL 执行效率高，几千行业务报表 SQL 可高效运行，同时文档齐全（含中文/英文）、社区活跃，学习与维护成本低。
- 优化架构支撑业务场景：当前 TiDB 集群（TiKV 7 节点、TiFlash 3 节点、TiDB 7 节点）承载全系统数据，总数据量 14.5TB，最大业务单表超 500GB、历史单表超 1TB，高峰期 QPS 达 20000+，支撑 8000+ 线下门店的业务报表与全局分析需求，业务报表最大并发达 300+。
- 规划未来架构升级：计划升级 TiDB 6.1 LTS 版本，利用 Placement Rule in SQL 实现冷热数据分离与资源隔离，借助新版本 TiFlash 提升并发与处理效率、TiKV 新日志引擎及内存锁优化写入效率；未来将演进为“两套 TiDB 集群”架构，按业务拆分集群并通过 CDC 同步数据，目标实现单库形态（TiDB HTAP 架构）支撑整个零售系统。
客户收益
- 查询效率显著提升： 绝大部分从 Oracle 迁移过来的 SQL 处理效率得到提升，即使是几千行的复杂业务报表 SQL 也能高效执行。
- 突破存储瓶颈： TiDB 的原生分布式架构支持灵活扩展存储空间，数据存储周期得以延长，彻底解决了 Oracle 的单机容量上限问题。
- 大幅降低成本： 彻底演进到 TiDB HTAP 单库形态后，预计可将数据同步通道从 100 多个降至 20 个左右，硬件资源成本降低约 50%，数据冗余度从 10 份降至 2 份，并大幅提升 DDL 操作和扩容效率。
- 加速精细化运营：TiDB 支撑当前海量数据与高并发需求，未来架构规划可进一步支撑全零售系统的分布式升级，满足数字化零售精细化运营的长期发展需求。