从蚂蚁集团数据库演进之路看未来数据库的选择

从蚂蚁集团数据库演进之路看未来数据库的选择 弓子介(泓影) 泛互联网&海外架构师负责人 第 一 OceanBase历程 十年磨一剑 篇 OceanBase发展历程及构架演进 1.0时代： 坚定走向分布式架构 2.0时代： 原生分布式数据库 3.0时代： 混合引擎、混合部署 4.0时代： 分布式一体化架构 2010 2013 2014 2016 2017 2019 2020 2021 2022 第一个用户 多个业务系统 支付宝交易金融级核心业务 核心账务核心交易支付 互联网核心系统 Oracle兼容公有云服务TPC-C6088万 HTAP引擎 TPC-C7.07亿 走向通用行业、更多头部客户核心系统 TPC-H1526万 社区版发布试点海外客户 单机分布式一体化架构 公有云上线 公有云北美站点开服 产品立项 扩大使用范围 核心交易上线 全业务覆盖 多家金融客户 打破世界纪录 独立商业化 规模化推广 公有云走向海外 批量处理，企业级特性，HTAP 技术栈：webx 系统1 系统2 系统3 技术栈：IOE Oracle主备切换Oracle 2004年 支付宝诞生的第一笔担保交易 2008年 一库闯天下 双11秒级支付峰值 SOA化-拆！拆！拆！(2008~2014年) 技术栈：SofaStack 200920102011 交易业务推进 支付业务推进账务 垂直拆分 交易分库1 交易分库2 交易分库3 交易分库4 交易备库1 交易备库2 水平拆分 交易备库3 交易备库4 支付主备切换支付 主库备库 账务主备切换账务 主库备库 技术栈：IOE 磁盘容量告警 CPU使用率告警 表太大了，不敢做DDL了 主备延迟了 数据库升级 实例部署 问题排查 数据坏块 性能又抖了连接数不够了 SQLReview 7*24oncall OracleDBA 时间碎片化 响应时间 机器又down机了，快切 数据量太大了，快帮我拆表 SQL调优 幸福感 A品牌策划与定 位 支付宝技术架构重大转折点 2015年527大规模瘫痪事件 舆情影响 第 二 OceanBase产品核心亮点 100%自主知识产权的分布式数据库 篇 多副本：一般部署为三/五个Zone，每个Zone由多个服务器节点（OBServer）组成,基于Paxos分布式协议的高效高可靠工程实现RPO=0,RTO<30秒，实现切换DBA无人值守 多租户：实现数据库内核级虚拟化，满足数据安全隔离的同时提供基于业务画像的可伸缩计算资源，同时通过Leader打散实现混部。 大集群：将长尾应用的多实例MySQL/Oracle统一进行管理，有效提高资源密度，消除存储碎片。 运维：通过整合运维对象由实例转变为集群，降低运维成本，提高单兵人效比。 P ZONE1 ZONE2 ZONE3 主副本从副本 •在线扩容增加每个高可用域（ZONE）的 OBServer P1 P2 P3 P4 OBServer P5 P6 P7 P8 OBServer P1 P2 P3P4 OBServer P5 P6 P7 P8 OBServer P1 P2 P3 P4 OBServer（新增） OBServer P5P6 P7P8 OBServer（新增） P6 OBServer（新增） P2 OBServer节点的数量 •数据库租户也增加资源单元 •系统自动将表/表分区的各个副本重均衡分布到新增加的ObServer节点 物理拷贝，每节点>500MB/s 无需重新hash每条记录 应用无感知，无需像分库分表那样对应用配合大量改造 P •同样支持在线缩容 写事务到达超过半数库 少数库异常不影响业务 两地三中心多活 灰度升级 基于Paxos协议的典型多副本(三副本或以上)部署： •数据强一致性 •持续可用 •主备自动切换，对上层业务透明 P •单机、机房、城市级故障：OB内部自动故障切换，不停服务（RTO<30秒），不丢任何数据 P （RPO=0） 主副本从副本 OBServerZ1-1 OBServerZ2-1 P1 P2 P1 P2 P3 P4 P3 P4 OBServerZ1-2 OBServerZ2-2 P5 P6 P5 P6 P7 P8 P7 P8 ZONE1 ZONE2 ZONE3 OBServerZ3-1上的P1/P2/P4和Z3-2上的P5/P6/P7均 OBServerZ3-1 P1 P2 P3 P4 OBServerZ3-2 P5 P6 P7P8 是从副本，它们各自剩下的1主1从两个副本依然构成多 数派，不影响业务； ZONE3机房整体故障，OBServerZ3- 1和Z3-2全部Crash！ P3的两个原从副本、P8的两个原从副各自本paxos协商出1个新的主副本提供服务 AZ1 OBnode1 AZ2 AZ3 tenant1 tenant2 tenant3 tenant4 leader follower follower follower leader follower leader follower follower follower follower leader PhysicalServer PhysicalServer 计算密度提升5倍 存储费用下降到1/5 OceanBaseCluster(5tenants)x1 MySQLx5 MySQL Physical Server database5TB OceanBase1TB •DBaSS能力，租户隔离(cpu/memoryresourceisolated) •机器资源充分利用 •按需分配资源(升配迅速) •读写能力都可以放在从节点上 存储成本至少省80%以上 数据编码机制以及lsm存储架构 无性能损耗 APP OBProxy APP OBProxy APP OBProxy 关键设计 •OBProxy与APP混部，数据链路无LoadBalance设备。 •P2P架构，单节点具备承担所有角色的可能。架构优雅，部署简单，无RPC通讯。 •一致性协议更换：Raft->Paxos •多租户：实现数据库内核级虚拟化，满足数据安全隔离的同时提供基于业务画像的可伸缩计算资源，同时通过Leader打散实现混部。 增量MemTable(WOS) Row-LevelIn-MemoryRedo/MVCC In-MemoryHash In-MemoryB+-Trees GetROWCache UpdatSmall-Querye Logs BlockCache ScanBig-Query MemoryDisk Replicas转储SSTable基线SSTable(ROS) 多个转储版本合并前合并后 关键设计 •基于LSM理念自研存储引擎，未采用RocksDB •宏块与微块：微块是数据的组织单元，宏块则由微块组成。Compact操作时，可以在宏块和微块两个级别判断，是否可以复用。•轮转合并：用多副本来解耦Compact操作和同时段的查询操作，避免磁盘I/O上的竞争。 •IO隔离：控制UserIO/SystemIO，减少对前台请求影响 •Encoding：按行存储，按列编码，类似GooglePAX行列混合存储，一套存储支持TP/AP。 •CheckSum：三副本compaction的checksum，•防止静默错误。 WritePath MemoryMemoryMemoryMemtableMemtableMemtable DiskDiskDisk TabletLogTabletLogTabletLog SSTable1SSTable1SSTable1SSTable2SSTable2SSTable3 1.Write2.Flush3.Compact Application SQL Execution miss PlanCache C1C2n hit SQLstatement FastParser AddtocachePhysicalPlan SQLCompiler ParserParseTreeResolver Stmt QueryTransformer XformedStmtOptimizer LogicalPlanCodeGenerator schema CostEstimator 关键设计 •Oracle/MySQL两套Parser，兼容MySQL5.7;Oracle11g•PlanCache：极大的节省语句的执行时间,几ms->几百us同时可以精细化的实现秒级的SQL限流、绑定。•SPM：计划灰度演进，确保永远往好的计划演进，不会出现 CBO代价模型选错计划。 •ACS：典型的大小账号场景：存在数据倾斜，不同的参数对应不同计划的问题，实现了自适应计划匹配。•大查询队列：查询队列优先级区分隔离，防止大查询将实例打爆 Client Machine State PaxosModule A=1A=1B=2 B=2Log Machine State PaxosModule PaxosModule StateMachine A=1 A=1 B=2 B=2 Log A=1 A=1 B=2 B=2 Log 123 4 5 6 7 8 9 #1-#3为已经持久化和应答的事务日志 #5-#9为已经收到但却不能持久化和应答的事务日志#4为未收到的事务日志。 关键设计 •Paxos与Raft：最本质的区别，在于是否允许日志空洞。Raft必须连续，不允许空洞。Multi-Paxos允许日志空洞存在，应对复杂网络环境，更为鲁棒。 •WAL：一次Clog（Tidb：raftlog/rocksdblog） 示例： •顺序投票策略对于主库的负面影响比较严重：出于性能提升的原因，数据库的多版本并发控制（MVCC）使得不存在相互关联的事务得以并发处理，但上述顺序投票策略使得事务#5-#9可能被毫不相干的事务#4阻塞，且必须hold在内存。 第 三OceanBase产品家族 篇 01评估改造 02实时迁移 03开发管理 04生产运维 05复制订阅 06安全管控 07诊断自治 自动采集 数据库画像 对象迁移 全量迁移 连接管理 对象管理 部署升级 资源管理 增量复制 双向同步 权限管理 操作审计 全链路监控 SQL诊断 自动转换 兼容性评估 增量迁移 数据校验 开发调试 导入导出 容灾切换 备份恢复 汇聚分发 数据抽取 安全协同 变更管控 容量管理 自动恢复 回放压测 分布式改造 增量回写 数据订正 数据可视化 模拟数据 监控告警 自动巡检 数据入湖 数据过滤 数据脱敏 安全治理 自动优化 智能运维 迁移评估工具OMA 数据迁移工具OMS 开发者工具ODC 运维管理工具OCP 数据收集 对象兼容性评估SQL/PL兼容性评估数据库/应用画像 源码评估 Oracle DDL转换 SQL/PL改造 配置推荐 修改适配 MySQL 评估报告 迁移计划 对接数据库迁移 OceanBase 性能报告 改造优化 业务压测验证 流量回放 流量采集 PostgreSQL SQL优化 SQL/PL改写 负载评估 全方位采集分析 支持直连到指定数据库或者通过OMA提供的数据库采集器，来自动获取和扫描源源端数据库系统中全部数据库对象以及自定义范围的SQL语句；提供兼容性评估分析、迁移可行性分析和风险分析。 智能改造方案 针对未完全兼容的场景，OMA会基于OceanBase多年沉淀的核心业务迁移以及大规模验证的转换方案最佳实践，提供迁移至OceanBase数据库的分布式改造方案。 多种数据库和对象支持 支持评估Oracle、MySQL、PostgreSQL、TiDB和DB2LUW等主流数据库的常用版本与OceanBase数据库的兼容性，包括Table、Index、View、Seq