3-4 弓子介-从蚂蚁集团数据库演进之路看未来数据库的选择.pdf

《3-4 弓子介-从蚂蚁集团数据库演进之路看未来数据库的选择.pdf》由会员分享，可在线阅读，更多相关《3-4 弓子介-从蚂蚁集团数据库演进之路看未来数据库的选择.pdf（24页珍藏版）》请在三个皮匠报告上搜索。

1、从蚂蚁集团数据库演进之路从蚂蚁集团数据库演进之路看未来数据库的选择看未来数据库的选择弓子介(泓影)泛互联网&海外架构师负责人OceanBase 历程十年磨一剑第一篇OceanBase 发展历程及构架演进1.0 时代：坚定走向分布式架构2.0 时代：原生分布式数据库3.0 时代：混合引擎、混合部署4.0 时代：分布式一体化架构多个业务系统产品立项第一个用户2010扩大使用范围2013核心交易上线支付宝交易金融级核心业务2014全业务覆盖核心账务核心交易支付2016多家金融客户互联网核心系统2017打破世界纪录Oracle 兼容公有云服务TPC-C 6088万2019独立商业化HTAP 引擎TPC

2、-C 7.07亿走向通用行业、更多头部客户核心系统2020规模化推广TPC-H 1526万社区版发布试点海外客户2021单机分布式一体化架构公有云上线公有云北美站点开服2022批量处理，企业级特性，HTAP公有云走向海外2004年支付宝诞生的第一笔担保交易系统1Oracle2008年一库闯天下技术栈：webx技术栈：IOE主备切换支付宝早期技术架构（2004年-2008年）系统2系统3Oracle支付宝早期技术架构（2008年-2014年）双11秒级支付峰值双11秒级支付峰值200920102011交易支付账务交易分库1交易分库2支付主库支付备库主备切换账务主库账务备库主备切换业务推进业务推进

3、交易分库3交易分库4交易备库3交易备库4交易备库1交易备库2垂直拆分SOA化-拆！拆！拆！(20082014年)技术栈：IOE技术栈：SofaStack水平拆分主备延迟了规模化运维带来的挑战CPU使用率告警表太大了，不敢做DDL了磁盘容量告警数据库升级机器又down机了，快切实例部署问题排查数据坏块性能又抖了数据量太大了，快帮我拆表连接数不够了SQL ReviewSQL 调优7*24 oncallOracle DBA时间碎片化响应时间幸福感支付宝技术架构重大转折点品牌策划与定位A2015年527大规模瘫痪事件舆情影响OceanBase 产品核心亮点100%自主知识产权的分布式数据库第二篇Oce

4、anBase 数据库产品架构Paxos协议+无共享架构+三副本多副本：一般部署为三/五个Zone，每个Zone由多个服务器节点（OBServer）组成,基于Paxos 分布式协议的高效高可靠工程实现RPO=0,RTO500MB/s 无需重新hash每条记录 应用无感知，无需像分库分表那样对应用配合大量改造 同样支持在线缩容P4P8P4P8P4P8P2P2P2P6P6P6P2P6P6主副本PP从副本核心优势-平滑高可用/容灾切换ZONE3 机房整体故障，OB Server Z3-1和Z3-2 全部Crash！P1P3P2P7OBServer Z1-1ZONE1P5P6OBServer Z1-2P

5、1P3P2P7OBServer Z2-1ZONE2P5OBServer Z2-2P1P2P3OBServer Z3-1ZONE3OBServer Z3-2Driver/ProxyP5P7P4P8P4P8P4P8P2P2P2P6P6P6P3的两个原从副本、P8的两个原从副各自本paxos协商出1个新的主副本提供服务主副本PP从副本OB Server Z3-1上的P1/P2/P4和Z3-2上的P5/P6/P7均是从副本，它们各自剩下的1主1从两个副本依然构成多数派，不影响业务；P6P8基于Paxos协议的典型多副本(三副本或以上)部署：数据强一致性 持续可用 主备自动切换，对上层业务透明 单机、机

6、房、城市级故障：OB内部自动故障切换，不停服务（RTO Paxos多租户：实现数据库内核级虚拟化，满足数据安全隔离的同时提供基于业务画像的可伸缩计算资源，同时通过Leader打散实现混部。关键设计描述OceanBase 存储引擎LogsUpdateReplicas增量 MemTable(WOS)ROW Cache转储 SSTable基线 SSTable(ROS)DiskRow-LevelIn-MemoryRedo/MVCCMemoryIn-Memory HashIn-MemoryB+-TreesScanBig-QueryGetSmall-QueryBlock Cache合并前多个转储版本合并后