多模一体化保障出行核心系统分布式升级

随着 T3 出行业务迅猛增长，日峰值订单数已突破 300 万。一套稳定、高性能且安全的数据库系统显得尤为重要。结合业务特点，T3 出行的数据库选型，需要综合考量性能、成本等多方面因素考量。

1. MySQL 存储的数据量非常有限
   1. T3 出行最初将其数据库部署在 MySQL 上。然而，随着订单量的快速增长，尽管 MySQL 能够支持很高的 KPS（每秒查询次数），但其存储的数据量却非常有限。当数据量达到几百万条时，系统便接近其上限，从而导致性能下降和内存消耗增加等问题。
2. 分库分表的技术局限性明显，带来资源浪费、成本增加等问题
   1. 首先，查询性能、灵活性不强，通常只能按照订单、司机或乘客等单个特定维度查询数据，不能进行多维度的查询。其次，数据库的水平扩展困难，且容易造成资源浪费。根据 T3 出行的业务画像，波峰波谷明显，非早晚高峰时段，大量的 MySQL 资源日常闲置；而早晚高峰时段，MySQL 连接数与规格绑定，数量有限，容易出现资源碎片化，导致数据库使用成本不断增加。
3. 技术栈众多，运营复杂且存在数据同步难题
   1. T3 出行使用 MySQL+HBase+MongoDB 等解决方案支撑数据存储与查询，目前，T3 出行系统运行着的 TP 和 AP 类数据库近 20 个，技术栈众多，需要耗费大量的资源和人力维护。且数据从 TP 数据库同步到 AP 数据库，涉及数据复制、提取、清洗等环节，每一次数据同步都有可能引起数据延迟或丢失，难以实现 100% 的完美迁移。

1. ​HTAP 实时分析混合负载
   1. 通过 OMS 将异构数据库分库分表迁移或同步至 OB Cloud，将多个实例融合为一个实例，摆脱维护中间件的苦难，分析查询的业务得以前置，无需等待 T+1 数据，直接于在线库中实现实时营销决策等分析需求。
2. 多模一体化，统一管理多数据类型
   1. 通过一个引擎原生支持多种数据访问模式，提供 Table API 接口兼容 HBase 接口，可通过一个数据库系统管理键值、JSON、GIS、XML、全文索引和 SQL 引擎查询等多种数据类型，在大规模数据存储和高性能读写场景中，用户能够实现高效的数据操作。
3. 高效存储引擎
   1. 基于 LSM-Tree 引擎，采用读写分离设计和行级细粒度记录更新，达成内存数据库写入性能和磁盘数据库的存储成本。通过行列混合存储格式，磁盘数据块按列组织，利用编码压缩大大降低存储成本。

一开始，T3 出行将司机任务、订单监控、虚拟号、开放平台等部分非核心业务作为试点，迁移至 OB Cloud 上。切换过程非常顺利，且运行稳定，在兼容性、成本与性能等方面表现良好。