主要观点总结
本文介绍了滴滴出行在面临MySQL数据库性能瓶颈时，引入分布式数据库OceanBase的选型和实施过程。通过对比测试和业务场景演练，验证了OceanBase在延迟、性能、稳定性等方面的优势，并成功解决了之前遇到的问题。同时，文章还分享了使用OceanBase的经验总结和未来规划，以及对OceanBase的期望和建议。
关键观点总结
关键观点1: 引入分布式数据库的背景和必要性
随着业务的增长，MySQL数据库面临性能瓶颈，需要引入分布式数据库解决方案。
关键观点2: 分布式数据库选型和测试
经过调研和测试多款分布式数据库，最终选择OceanBase作为解决方案，并通过定向压测和场景演练验证了其满足业务需求。
关键观点3: OceanBase解决的业务问题
OceanBase成功解决了MySQL在使用过程中的性能、效率、成本、一致性等方面的问题，提升了业务迭代效率。
关键观点4: OceanBase的应用效果
上线OceanBase后，业务延迟缩短了近10倍，性能提升明显，稳定性得到业务同学的一致认可。
关键观点5: 未来规划和期望
计划扩大OceanBase的使用规模，加强运维能力，并对OceanBase提出全局自适应限流、增加核心字段校验、更方便的多租户拆分能力等期望或建议。
文章预览
作者 | 吴其朋
策划 | 冬梅 滴滴出行作为涵盖网约车、出租车、顺风车、代驾等业务的一站式多元化出行平台，拥有全球客户 6.5 亿。在平台出行种类十余种且服务如此体量的用户时，滴滴出行的底层数据库主要采用 MySQL，且拥有上万套集群。其中单实例超 2TB 的集群为 400+ 套，最大的集群规模为几十分片，数据总量已超百 TB。还有数十套非 Innodb 引擎的 MySQL 服务如 RocksDB、TokuDB 等。 然而，底层数据库矩阵随着业务的高速增长逐渐在性能、效率，成本，一致性这四个方面显露瓶颈。 首先，某业务在访问 MySQL 百亿大表时，延迟高达上百毫秒，造成业务 SQL 超时，影响业务流程。同时，因为该表有事务依赖，所以无法通过拆表的方式提升其访问性能。 其次，由于审计和业务需求，核心归档服务中需要保留大量历史数据，导致服务存储量高达几十 T
………………………………
