OceanBase案例集 2023

OceanBase案例集   / 作者 大窑 冰魂 樊序 宫博 孤樵 姜徕 京初 旻赫嵩拓 桐杺 想先 秀明 言序 亦年 元藏 翊严真难 / 致谢 奥星 禅觉 方员 格宗 海芳 计无 空居 理香妙云 鸣仙 鹏舞 晴岚 易过 永昆 元博 / 编辑斯氪 柒月 / 设计千户 艳玲 *以上排名不分先后，按姓名首字母排序 内部刊物 本刊为内部刊物，而非商业用途。本刊任何文字和图片均不容许以任何方式公开转载，违者将诉诸法律手段处理。 目录 01 04 服务民生夯实「稳定可靠」 顺势而生打造「顶天立地」的产品 深圳公积金：数字化再升级，打通市民办事的“最后一公里”江西人社：首个接入全国统筹信息系统数据库国产升级雄帝科技：当城市公交装上“智慧大脑”江苏移动：首“战”告捷，核心技术自主可控 支付宝：跳下巨人的肩膀网商银行：国内第一家“三地五中心、多地多活”银行 05 02 内生外化选择最难「啃」的银行系统 小即是大助力中小企业「提效降本」 南京银行：国内首个商业银行互联网金融核心分布式升级中国工商银行：“宇宙行”的关键业务系统转型云南红塔：新一代核心系统稳中求进，蝶变向新常熟农商银行：“合芯”重塑金融科技核心业务系统 携程：改造旧支点，撬动新价值海底捞：踢走智慧餐饮路上的最后一块绊脚石理想汽车：造车“新势力”遇见数据库“新势力”二维火：告别分库分表，以变应变致欧家居：打造多云融合的分布式跨境电商 03 06 走向世界引领中国科技「扬帆出海」 持续打磨「扎根」金融级场景 GCash：开启云端数据存储新篇章 中华保险：“大象”转身，重构核心招商证券：征战新时代，紧抓新机遇 顺势而生 打造「顶天立地」的产品 2010 年，阳振坤受邀加盟淘宝，由此拉开 OceanBase从零开始完全自主研发的序幕。从第一个 “勇敢” 的用户——淘宝收藏夹，到稳定支撑支付宝全部核心链路， OceanBase 顺应大数据时代而生。 经过淘宝、 天猫、 支付宝、 网商银行、 菜鸟、 高德等内部海量复杂场景的长期淬炼， OceanBase 已经具备数据强一致、 高扩展、高可用、高性价比、高度兼容 Oracle/MySQL、稳定可靠等特征。 谈及 “顶天立地”， OceanBase 创始人及首席科学家阳振坤曾表示 ：做“顶天立地”的技术， “顶天”就是技术上要有突破，“立地”就是要把产品做成通用产品，让整个社会都能使用。 支付宝：跳下巨人的肩膀 支付宝是中国的第三方支付服务平台，于 2004 年 12 月 8 日独立运营。目前，支付宝的全球用户数已超12 亿，并与超过 200 家金融机构达成合作，为上千万小微商户提供支付服务。随着场景拓展和产品创新，支付宝已经发展成为融合支付、生活服务、政务服务、理财、保险、公益等多个场景与行业的开放性平台。 蚂蚁集团是移动支付平台支付宝的母公司，也是全球领先的金融科技开放平台。支付宝作为蚂蚁集团的全资子公司，也是中国支付领域的领跑者和标杆企业。2012 年， OceanBase 原生分布式数据库从淘宝转战支付宝， 并于 2014年“双 11”承受住了原计划 1%，实际 10% 交易流量的终极大考。此后连续十年，OceanBase 平稳助力支付宝在“双11”期间捷报频传，一往无前。 目前，OceanBase 原生分布式数据库运行着数十亿条不同的 SQL、数据量达数百 PB、服务器核数过百万，并且已经完全覆盖支付宝全部核心链路，支撑全部五大业务板块。 巨人的肩膀上没有巨人 数据库作为基础软件，研发耗时较长且投入巨大，因此，很长一段时间国内过半的数据库市场都被 Oracle 这样的老牌数据库厂商霸占着。Oracle 数据库广泛遍布于我国制造业、 金融、 政府、 通信系统中， 即使到了 2015 年， 仅Oracle 一家的市场份额也还有 56% 之多。 曾经，阿里巴巴拥有亚洲最大的 Oracle 集群，但随着互联网、云计算等技术的快速发展，数据量呈爆炸式增长，数据环境千变万化，数据类型越来越多，再加上用户需求的个性化，交互行为的实时性，导致传统数据库和传统的数据处理方式已经很难满足对数据的处理要求。此外，传统数据库的可靠性、高可用性等都需要依靠极其昂贵的硬件来实现，成本高昂。 同时，阿里巴巴高峰时和平峰时流量差别巨大，通过硬件实现特殊日期的高流量支持会造成严重的资源浪费。综上所述，现有的商业数据库无法很好地支持阿里巴巴的整个互联网产业。 支付宝OceanBase 2013 年前后，市面上过半企业在搭建 IT 基础体系时都会首选“IBM 小型机 +Oracle 数据库 +EMC 存储” 的传统搭配，这三大海外巨头从软硬件上控制了大多数国内企业的发展命脉，这种高度依赖海外软硬件的现状不仅给企业带来了极大的 IT 成本负担，更是将数据安全置于诸多隐患中。 巨人的肩膀上，没有巨人。如果想要获得更加长久、安全、稳定的收益，摆在阿里巴巴及蚂蚁集团面前的就只有一条路 ：走出依赖，从头自研。 OceanBase 完全覆盖支付宝全部核心链路连续 10 年稳定支撑“双 11”流量洪峰仅存储一项，节省约 20 亿成本 十年磨一剑，OceanBase 越来越能打 2009 年，支付宝迎来第一个“双 11”，与之而来出现“峰值脉冲”，原单库单表的集中式数据库方案一时间无法抗住如此高的流量冲击。所以，支付宝在很早期就进行了拆库拆表，由此诞生了基于中间件方案的第一代分布式架构。 异 构 数 据 库 迁 移 是 一 个复 杂的 过 程——主 要 是 兼容 性 和 数 据 质 量 的问 题。为了高 效 迁 移， OMS （OceanBaseMigration Service，OceanBase 数据迁移工具）提供一站式的异构数据库上 OceanBase，首先为了应对兼容性问题，平台提供静态代码评估，动态流量回放评估，其次数据质量通过全量校验，增量校验，离线校验等多重手段实时保证数据一致性。 OceanBase 0.1 版本最初用于存储淘宝用户收藏条目和具体的商品、 店铺信息，每天支持 4 ～ 5 千万的更新操作。但当收藏夹中保存宝贝和店铺的详细信息达到数亿条、 信息条目达到数十亿条时， 收藏夹开始难堪重负。于是OceanBase 团队在技术上采取了两个对应策略 ： 第一个策略是把数据分成基线和修改的增量，基线放硬盘，修改的增量放内存。即整个数据库以硬盘（通常是 SSD）为载体，新近的增、删、改数据（“修改增量”）在内存，而基线数据在保存在硬盘上，因此 OceanBase 可以看成一个准内存数据库。 当时面临的另一大挑战就是数据的高可用、系统的高可用。为此，OceanBase 团队决定在关系型数据库上第一次采用三副本架构，在三个副本中选两个副本，当两个副本达到一致，整个数据也就达到了一致。 随着支付宝业务的迅猛发展，OceanBase 身上的担子越来越重。生产库磁盘不足、IOPS 性能下降、备份时间变长都成了压在 OceanBase 身上的“大山”，这时数据的归档变得尤为重要。 过去，高效且低成本将数据归档只有两条路可选 ：要么引入高端商业存储阵列，要么引入新一代分布式存储。现在，只需要用 SATA 盘加上 X86+OceanBase 的分布式能力，就可以轻松搞定单库 PB 级存储。 其实，经验总结起来就是两个核心点，即负载均衡和故障恢复。 第二个策略是半分布式结构，也就是先采用一个中心的写节点加上多个读节点，读是分布式的，写是集中式的。 负载均衡最主要的目的就是在成本尽量低的情况下让存储利用率和计算资源利用率都达到最大化。 当时收藏夹采用了这个解决方案后，服务器的数量从原来预计的第二年要用到几百台，降低至二十几台，服务器成本节省了 90% 以上。 故障恢复就是不论故障机器是否彻底宕机， 替换的新机器都会作为目标迁入数据， 瓶颈都在新机器单机的写入能力。按照普通 SATA 盘 200MB/s 的写入能力计算，100TB 数据迁移几乎需要一周时间。过长的替换时间会带来诸多弊端，如可能出现二次宕机出现单副本，变更周期过长，容易出现失误等。 2014 年“双 11”，OceanBase 迎来了第一次大考，最终成功支撑了当年“双 11”10% 的交易流量。经此一役，得到了更多的认可和支持，到了 2015 年“双 11”，OceanBase 已经承载了 100% 的交易流量。 鉴于此，研发团队利用 OceanBase 的原生分布式能力，加速替换。具体分为两步 ：首先新机器上线，其次故障机器直接永久下线，OceanBase 的总控服务 RootService 检测副本缺失，直接走补副本模式，补副本是多机到多机拷贝，生产可达 30-50GB/s，100TB 数据迁移只需两三个小时就可以完成。 但由于 OceanBase 0.5 版本还是维持中心单一的写节点，随着业务的发展，瓶颈愈发突显。于是，2014 到 2016 两年间，OceanBase 团队将绝大部分资源都投入到由“半分布式”向“全分布式”转变上，让各个点都能写入。 在 1.0 时代，OceanBase 实现了一个集群内所有节点都是对等的，每个节点都可以进行读写，成为了真正的分布式数据库。此外，凭借着多租户、高可用、弹性伸缩三大性能优势，1.0 版本成为了支付宝投产时间最长、应用范围最广的版本。 仅存储一项，节省约 20 亿成本 迁移至 OceanBase 后，比较明显的收益有两点 ：一是效率大幅提升，DBA 可以更从容地应对日常的容量容灾问题，日常容量应急、故障切换配合运维体系已经完全自动化，计划内的大促弹性和容灾演练都可以一键完成。值得一提的是，基于原生分布式架构，OceanBase 在支付宝可以做到“三地五中心“的多副本多活模式的高可用 2017 年“双 11”期间， 数据量呈现出爆炸式增长， 1% 的压力峰值就已经超过了单库单机的最大容量。传统数据库扩容方案主要依赖分库分表拆分进行水平扩容， 用多套库的方式共同扛流量峰值。虽然这种方案可行，但存在很多弊端，比如多套数据源、多套 DB 集群，增加了配置管理、日常管理成本。 二是 成 本 极 大降 低， 一方 面 OceanBase 的多租 户整 合 Oracle/MySQL 长 尾业 务， 优化碎片资源， 另一方 面OceanBase 的高级压缩技术，使得同一业务的数据存储量仅为 Oracle/MySQL 的 1/4-1/3。对比于最初的应用，计算资源投入降低为原来的 1/12， 同时 OceanBase 支持冷热数据分离， 可以将较少访问的数据迁移到低成本 HDD存储上，进一步降低存储成本。若按支付宝数据体量在 100PB 左右计算，仅存储一项，相比 Oracle 节省存储成本约20 亿。 这时业务侧需要一个更优雅的分布式数据库解决方案，即只使用一个库，就可以支持百万甚至更高的支付峰值，让横向扩容直接在数据库闭环，做到应用不感知，OceanBase 2.0 分区提供了完美的解决方案。 OceanBase 2.0 沿用了传统数据库分库分表拆分的思路，在用户无感知的前提下把数据拆分到更多的机器上，突破单机性能瓶颈，自动负载均衡，从而实现稳定支撑每秒百万笔支付请求的能力。同时，当分布式事务退化为单机事务时也能做到极致性能。OceanBase 2.0 版本凭借高兼容、低成本、极致弹性和低运维成本等特点在支付宝承担了更多的核心业务。 OceanBase 当初没有选择基于开源或已有的技术思路开发，而是选择走分布式自研这条路，这条路虽然难走，但现在来看这已经成为了其不可替 代的优势。随着 OceanBase 4.0 （业内首个单机分布式一 体化数据库） 的发布，OceanBase 也从金融级数据库这条蜿蜒细流游向了通用数据库的星辰大海。 紧抓两大核心点，完成异构数据库迁移 如今，OceanBase 早已走出支付宝、走出阿里巴巴及蚂蚁