携程数据库 携程数据库表设计

基础设计规范

为确保系统稳定性和数据完整性，我们设定了严格的基础设计规范。存储引擎统一使用InnoDB，以保证数据完整性和并发访问的效率。出于同样的考虑，我们禁止其他存储引擎的使用。每一数据表都必须拥有独立的主键，我们不支持联合主键的使用，以简化数据查询和维护流程。为了保证数据的完整性和准确性，我们采用utf8mb4字符集，支持emoji表情等多样字符。每一表必须包含modifytime字段，并对其进行索引优化，同时推荐使用createtime字段来记录数据的创建时间。出于系统稳定性的考虑，我们暂时禁用外键约束，关联关系将通过应用层逻辑进行维护。

典型表结构示例

以机票预订模块为例，我们的典型表结构如下：

国家表（ctrip_area_country）：包含国家ID、中英文名称等基础信息字段；

省份表（ctrip_area_province）：包含省份ID、中英文名称等关键信息字段；

城市表（ctrip_area_city）：包含城市ID等基础信息字段，为我们的地理位置服务提供支持。

分布式设计

面对日益增长的业务需求和不断提升的数据规模，我们采取了分布式设计策略。为解决单机瓶颈问题，我们采用水平分库分表策略，如国际火车票业务按订单ID进行分片处理。我们引入了Sharding-Sphere中间件，以简化分布式环境下的路由处理和跨库事务管理。为了应对业务增长带来的数据存储和处理压力，我们引入了TiDB分布式数据库，实现系统的弹性扩展和强一致性。

演进过程

我们的系统经历了不断的优化和演进。早期我们从SQLServer迁移到MySQL，逐步建立起完善的发布系统，实现对DDL变更的精准管控。我们通过分环境（Dev→FAT→LPT→UAT→Product）实现灰度发布流程，确保每一次变更都能平稳过渡。在表结构重构过程中，我们清理了废弃字段，如酒店产品主表从原本的200+字段精简至必要的信息，提升了系统的运行效率。

实时数据处理

为了满足实时数据处理的需求，我们采用了Lambda+OLAP混合架构构建实时数仓。具体而言，我们使用Flink处理实时流数据，确保数据的实时性；而OLAP引擎则负责数据的聚合计算，满足复杂的分析需求。这种架构既保证了数据的实时性又满足了复杂查询的需求。