谈谈对OceanBase单机分布式一体化的思考

关于作者:

杨传辉,OceanBase CTO。2010 年作为创始成员之一加入 OceanBase 团队,主导了 OceanBase 历次架构设计和技术研发,从无到有实现 OceanBase 在蚂蚁集团全面落地。同时,他也主导了两次 OceanBase TPC-C 测试并打破世界纪录,著有《大规模分布式存储系统:原理与实践》。目前,杨传辉带领 OceanBase 技术团队致力于打造更加开放、灵活、高效、易用的下一代企业级分布式数据库。

我从 07 年开始研究大规模分布式系统,刚开始参照 Google 三驾马车(GFS / MapReduce / Bigtable),10 年开始加入当时的淘宝做 OceanBase。

OceanBase 最初是一个分布式架构,支持的 SQL 功能非常有限,后来逐步加入 SQL 功能并通用化。刚开始接触大规模分布式系统的时候,我觉得这个领域特别高大上,当年的分布式系统有点像今天的 ChatGPT,涉及的技术很前沿,而且有些协议非常难,我记得当时仅仅理解 Paxos 协议就花费了一年多的时间,看了十几篇相关论文且和小伙伴们做了大量的技术讨论。

曾经有一段时间,我觉得分布式是 IT 软件技术皇冠上的明珠,所有系统只有做成分布式才显档次。但是,当我们将 OceanBase 早期版本应用到淘宝和支付宝时,用户和 DBA 给我们提出的都是 SQL 兼容性和性能成本相关的需求,把我们和单机的 MySQL 数据库做比较,只有完全兼容且性价比更高才会选择 OceanBase。他们告诉我,OceanBase 的扩展性和无损容灾确实很好,也认同分布式这个方向,但是对不起,老板说今年业务发展太快,不能投入额外人力做数据库改造,也不能投入额外的数据库服务器。

过去有一句土话叫“既要也要还要”,小孩才做选择,用户和 DBA 想要的就是一个不要做选择的“成年人的数据库“。我记得当时还和 Google Spanner 的研发人员做过一次技术讨论,我问他们为什么 Google 内部能够接受 Spanner 很差的单机性能,他们告诉我 Google 内部的程序员很强,大家都可以把应用修改为异步程序。另外一点就是,Google 有 Jeff Dean,只要他想统一基础架构就可以自上而下推进。我很羡慕 Google 内部做基础设施的研发人员,同时,我也意识到,这种模式是不可扩展的。对于开发者来讲,一定要把单机的高性能低门槛融入到分布式的可扩展高可用才能做出一个真正好用的分布式数据库。

我们在 2016 年发布了全分布式架构 OceanBase 1.0 版本,这个版本的所有节点都是可读可写的,但是,有一个问题,那就是每个节点用于分布式相关的 overhead 比较大,当表格和分区较多时,即使系统空转,也会消耗好几个 CPU 核用于分布式相关操作。这个问题使得 OceanBase 1.x 系列的版本只能帮助较大规模的企业解决数据库的问题,很难在中小企业做规模化复制。

于是,我们在 2018 年开始讨论如何降低分布式数据库的门槛,让分布式数据库成为一个人人皆可触达的东西。数据库底层架构的调整需要非常慎重,我们足足花费了两年多的时间完成了技术讨论和总体架构的设计,并在 2020 年年中左右开始做详细设计和代码开发,再经过两年多的时间才在 2022 年 8 月份发布了第一个 OceanBase 4.0 版本,代号“小鱼“。4.0 版本奠定了单机分布式一体化架构的底座,但是还有很多的遗留问题,在 3 月份开发者大会发布的 4.1 版本中解决。

我们从 2021 年开始对外铺垫一体化架构的概念,最早的一体化架构叫做“集中式分布式一体化“,当时我们认为 DBA 更加熟悉集中式这个说法。不过,市场品牌的负责人建议修改成 “单机分布式一体化”,这样会更加形象直观,能够更好地表达 OceanBase 的技术特点,开发者也更容易理解。

图片

架构设计首先要做的就是可行性分析。做技术的同学肯定都很熟悉,架构设计的核心在于取舍,为什么能够做到,背后的原理是什么,舍弃了什么。我们在设计一体化架构时,也做了一个设计假设,那就是:对于一个分布式数据库,虽然数据量很大,但是大部分操作仍然为单机操作(>80%),少部分操作才是跨机操作(<20%)。

OceanBase 早期在阿里系内部推广时,我自己就是内部的 BD/SA,我会主动去和每个业务的开发人员交流,最后发现,虽然阿里系的业务很复杂,有电商,金融,物流,本地生活,文娱,地图,医疗健康,但是,所有的互联网 to C 的在线业务基本都能够按照用户号(user_id)做 sharding 来实现分布式。按照 user_id 做完 sharding 之后,绝大部分操作都是单用户内部的操作,只有非常少数的跨用户操作。

金融行业也是类似的,我们都用过网银系统,大部分时间都是在读写自己的账户,少部分时间才是做转账这样的跨账户操作。于是,系统的优化目标就变成:首先确保 80% 的单机操作没有任何分布式相关的 overhead,这部分操作能够和单机数据库站在同一个起点上 PK 性能,接下来才是优化另外 20% 跨机操作的性能,尽可能追求极致。

单机操作的分布式相关 overhead 主要来自于两个方面:一个是高可用带来的,一个是可扩展性带来的。2013 年的时候当时的支付宝 Oracle DBA 告诉我一个经验数据,当 Oracle 打开强同步的时候,性能降低至少 30% 以上。OceanBase 为了实现无损容灾,底层采用了基于 Paxos 的强同步方案,如果不在架构上有所变化,肯定做不到单机高性能。


我们的做法是把数据库中的 redo 日志提交给异步化,这样就避免了数据库内部的工作线程等待日志提交返回结果,即使网络和磁盘比较差,强同步带来的开销也比较小。我们用 sysbench 对 OceanBase 三台机器强同步做了性能评测,结果表明 Paxos 强同步对于 OceanBase 的性能损失只有 8% 左右。这个损失是完全可以接受的,可以通过其它模块的优化给弥补回来。可扩展性带来的性能损耗主要是数据分片导致的,每个数据分片都需要写单独的redo日志,可以简单地把每个数据分片想象成一个 mini 数据库,分片越多,每台机器上分片管理相关的分布式 overhead 就越大。

4.0 单机分布式一体化架构的创新就在于动态日志流。每台机器上的每个租户只有一个日志流,这个租户上的所有数据分区都动态绑定在该日志流之上,从而避免了大量日志流导致的 overhead。另外,分区到日志流是动态绑定的,当系统增加新的服务器时,可以把分区从源端的日志流动态解绑并重新绑定到目的端的日志流,从而实现分区动态迁移。

很多人可能会想,数据库发展了这么多年,为什么 OceanBase 想到了这么做,其他人都没有想到?这里面其实也没有什么魔法,我认为关键点在于全球分布式数据库很少有像 OceanBase,必须扛住支付宝双十一这样的极限业务场景,并且多年被业务方”既要也要还要”给逼出来的。

业界对于可扩展性也有不同的做法:经典的单机数据库干脆就不支持可扩展,想要分布式的时候让应用做改造;NewSQL 系统的思路是把可扩展性下沉到存储层,将系统划分为 SQL 层和存储层,SQL 层做功能,存储层做可扩展性,这种实现方式更加简单,但会带来一个问题,那就是每个 SQL 请求都需要一次额外的远程访问,即使是访问自己账户也是一样;OceanBase 的做法是先实现全分布式架构 1.x/2.x/3.x,再逐步演进到单机分布式一体化架构 4.x。

图片

单机分布式一体化架构看起来什么都行,既能做单机,又能分布式,现阶段的侧重点到底是什么?我认为一方面,单机分布式一体化架构是一种技术的升维,对于用户和开发者比之前更加友好,会逐步成为主流选择。另一方面,新技术肯定有一段成熟期,尤其是用户体验和生态一开始不如单机数据库,需要一段时间来打磨。短期来看,单机分布式一体化架构对于开发者的价值在于如下几个方面:

第一,极大地降低分布式数据库的门槛。原先的 NewSQL 单机性能太差,业界主流的 NewSQL 系统,比如 CockroachDB 和 YugabyteDB 的单机 sysbench 性能只有 MySQL 的 1/5 ~ 1/10。随着单机分布式一体化数据库逐步成熟,这类 NewSQL 会被逐步取代,我也确实看到很多用户把原先使用的 NewSQL 系统换成  OceanBase 来实现降本增效。

第二,解决用户从小到大扩展的需求。我在和很多中小企业沟通的过程中发现,大多数中小企业都是很有追求的,虽然目前阶段他们的数据量不大,单机数据库也能支撑,但是他们也对未来几年的业务发展充满期待,不希望等到业务发展之后再修改应用更换数据库,他们愿意一开始就选择单机分布式一体化数据库。

单机分布式一体化数据库最终会不会取代单机数据库?我认为从技术趋势上来看会逐步替代,但是整个过程比较长,需要很长一段时间。

图片

单机分布式一体化架构的核心技术是动态日志流。为了真正实现一体化,需要解决如下几个关键的技术问题:

  • 应用透明:从单机到多机不需要应用做改造,需要客户端支持动态路由技术,当后端数据库发生分区迁移时,能够动态路由到目的服务器上。另外,不管是单机还是分布式,需要支持全部的 SQL 功能。

  • 单机操作:单机只有一个 redo 日志,单机事务写 redo 日志的方式与经典的单机数据库比较像。OceanBase 还做了一项技术创新,经典的单机数据库采用的是B+树存储引擎,OceanBase 的做法是将 B+ 树数据分块的思路融入到 LSM 树存储引擎,一方面能够像 LSM 树一样具备高压缩能力,并把热点数据放在内存中提供服务,另一方面通过类似 B+ 树的数据分块思路来减少 LSM 树的写入放大。最终使得 OceanBase 4.1 即使在三台机器做强同步的情况之下无论是单机的性能还是存储成本都好于 MySQL 8.0。 

  • 跨机操作:跨机操作通过底层的分布式架构提供,上层的 SQL 功能不受影响。如果事务只涉及一台机器,走单机事务;如果涉及多台机器,通过两阶段提交实现分布式事务。另外,通过分布式、并行、异步化等技术手段尽可能地优化性能。

  • 迁移代价:迁移操作后台进行,实际运行时一般会对迁移限速。假设迁移最大限速 200MB/s,占用万兆网卡 20% 左右的带宽,迁移操作只是拷贝数据,CPU 占用比较少,只要不是在双十一零点这样的极端场景,后台迁移都不会影响前台的在线交易请求。假设数据量为 1TB,迁移时间为 1TB / 200MB/s = 5000s,大约 1 个半小时。

图片

今年 3 月份我们在开发者大会分享了 OceanBase 的性能数据,过去也在 TPC-C 测试展示了 OceanBase 的扩展能力:

  • 单机性能:32C 场景,OceanBase 4.1 在 sysbench 所有场景(point select/read only/write only/read write/insert/update)都好于 MySQL 8.0,在最为综合的 readwrite 场景 OceanBase 4.1 比 MySQL 8.0 高 39%。

  • 公有云性价比:采用 4C16G CPU,MySQL 部署主备两台机器,OceanBase 部署三台机器,两台为全功能副本,一台为日志副本。无论存储多大,从 100GB,300GB,500GB 到 1TB,OceanBase 4.1 在阿里云和 AWS 的性价比都好于MySQL 8.0,且存储容量越大,OceanBase的优势越明显。整体上看,同样的性能,相比云上的 MySQL,OceanBase可以帮助用户节省 18.57% 到 42.05% 整体拥有成本,且 OceanBase 还有更好的三副本无损容灾能力。

  • TPC-C 扩展性:OceanBase 参加过两次 TPC-C 测试,最后一次测试中采用了超过 1500 台机器,TPC-C 的 workload 里面有 10%~15% 分布式事务,本地事务 85%-90%,与真实场景比较接近。通过 TPC-C 官网公布的报告可以看到,OceanBase 的性能基本能够做到随着服务器的增加而线性增长。

图片

当然,单机分布式一体化架构也不是完美的,有一些问题仍然值得探讨,也希望未来和开发者用户做更深入的探讨:

一、分布式到单机 vs 单机到分布式

到底是选择分布式到单机(先做分布式再做单机),还是单机到分布式(先做单机再做分布式)的技术路线?我认为只有分布式到单机才是可行的。因为分布式的技术难度比单机要高一个数量级,再加上单机的场景是主流场景。从 ROI 的角度看,不太可能出现一个主流场景的单机数据库,在已经有大量技术债的前提之下,舍弃部分主流场景的支持,花费更高一个量级的代价去支持一个规模更小的高端场景。这也是为什么所有的商业案例中,只有先做高端,再做低端的降维做法才能成功。

技术创新也往往在外部才会发生,比如电动车领域的 Tesla,分布式技术有点像电动车的电池,并不是燃油汽车厂商在内部实现了电动化的变革,而是一个外部的 Tesla 先做好高端的 Model X/Model S,再逐步通过大众车 Model 3 去占领主流市场。

二、全分布式场景

单机分布式一体化架构有一个假设,那就是:在分布式数据库中,大部分请求仍然是单机读写,少部分请求才是跨机读写。如果这个假设不成立,也就是大部分请求都是跨机读写,那么,分布式数据库性能的扩展比会大幅下降。怎么看待这个问题?我认为可以进一步把全分布式的场景分为两类:一类是 OLAP 场景,OLAP 场景单个用户的数据量都很大,且维度会比较复杂,这个场景确实很难做到本地化。

但是,这个场景的并发量很小,优化的关键点在于尽可能地把所有机器的资源通过并行化、向量化等手段尽可能地利用起来。每次运行的 SQL 都比较大,一次额外的网络请求开销在整个 SQL 语句执行过程中占比很少。另外一类是 OLTP 场景,假设某个 OLTP 业务全部都是跨用户转账操作,那么,如果数据量比较小,单机分布式一体化架构可以只部署单机,没有额外的分布式开销;如果数据量比较大,必须采用多机部署,那么,性能的扩展比虽然会大幅下降,但是,这是业务无法避免的,这种场景下单机分布式一体化数据库相比其它的 shared nothing 数据库在架构上也没有劣势。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/125019.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

管理类联考——数学——汇总篇——知识点突破——数据分析——计数原理——排列组合——成双

&#x1f30a; 配对问题的解题思路&#xff1a;配对问题主要以鞋子或者手套来作为命题对象&#xff0c;其核心在于成双不成双&#xff0c;对于成双问题&#xff0c;直接选取整双即可&#xff0c;对于不成双问题&#xff0c;要先取成双的&#xff0c;然后从每双中取单只即可。 …

go语言学习笔记

Go学习 一直想学一门新语言&#xff0c;难度又不想太大&#xff0c;C和Java都会但是不怎么精通&#xff0c;某天看到Go语言&#xff0c;好的&#xff0c;就是它了。总体来说&#xff0c;go语言的学习还是相对简单&#xff0c;有编程基础的入手很快。 简介 go是一种并发、带垃…

【设计模式】一、设计模式七大原则

文章目录 设计模式概述设计模式七大原则设计模式的目的设计模式七大原则1. 单一职责原则2. 接口隔离原则3. 依赖倒转(倒置)原则4. 里氏替换原则5. 开闭原则&#xff08;Open-Closed Principle简称OCP原则&#xff09;6. 迪米特法则7. 合成复用原则&#xff08;Composite Reuse …

ABB REF615C-D HCFFAEAGABC2BAA1XD控制继电器

多功能保护&#xff1a;REF615C-D 继电器具备多种保护功能&#xff0c;包括过流、短路、地故障、欠频、过频、欠电压、过电压等&#xff0c;可用于监测和保护电力系统中的设备。 通信能力&#xff1a;该继电器支持通信协议&#xff0c;如IEC 61850、Modbus等&#xff0c;使其能…

YOLOv5算法改进(11)— 替换主干网络之EfficientNetv2

前言&#xff1a;Hello大家好&#xff0c;我是小哥谈。EfficientNetV2是一个网络模型&#xff0c;旨在提供更小的模型和更快的训练速度。它是EfficientNetV1的改进版本。EfficientNetV2通过使用更小的模型参数和采用一种称为Progressive Learning的渐进学习策略来实现这一目标。…

Benchmarking Chinese Text Recognition: Datasets, Baselines| OCR 中文数据集【论文翻译】

基础信息如下 https://arxiv.org/pdf/2112.15093.pdfhttps://github.com/FudanVI/benchmarking-chinese-text-recognition Abstract 深度学习蓬勃发展的局面见证了近年来文本识别领域的迅速发展。然而&#xff0c;现有的文本识别方法主要针对英文文本。作为另一种广泛使用的语…

NIFI实现JSON转SQL并插入到数据库表中

说明 本文中的NIFI是使用docker进行安装的&#xff0c;所有的配置参考&#xff1a;docker安装Apache NIFI 需求背景 现在有一个文件&#xff0c;里面存储的是一些json格式的数据&#xff0c;要求将文件中的数据存入数据库表中&#xff0c;以下是一些模拟的数据和对应的数据库…

初试小程序轮播组件

文章目录 一、轮播组件&#xff08;一&#xff09;swiper组件1、功能描述2、属性说明 &#xff08;二&#xff09;swiper-item组件1、功能描述2、属性说明 二、案例演示&#xff08;一&#xff09;运行效果&#xff08;二&#xff09;实现步骤1、创建小程序项目2、准备图片素材…

工程管理系统简介 工程管理系统源码 java工程管理系统 工程管理系统功能设计

鸿鹄工程项目管理系统 Spring CloudSpring BootMybatisVueElementUI前后端分离构建工程项目管理系统 1. 项目背景 一、随着公司的快速发展&#xff0c;企业人员和经营规模不断壮大。为了提高工程管理效率、减轻劳动强度、提高信息处理速度和准确性&#xff0c;公司对内部工程管…

微信小程序 房贷计算器 js代码终极版

这里写目录标题 展示图1.在utils 中创建文件calculateMortgage.ts2. 在需要使用的地方引入并传参 展示图 1.在utils 中创建文件calculateMortgage.ts /** 假设房贷本金是60万&#xff0c;贷款年利率为4.8%即月利率为0.4%&#xff0c;分20年即240期偿还&#xff0c;等额本金还款…

AWS-数据库迁移工具DMS-场景:单账号跨区域迁移RDS for Mysql

参考文档&#xff1a; 分为几个环节&#xff1a; 要使用 AWS DMS 迁移至 Amazon RDS 数据库实例&#xff1a; 1.创建复制实例 有坑内存必须8g或者以上&#xff0c;我测试空库 都提示内存不足 2.创建目标和源终端节点 目标空库也得自己创建哈 3.刷新源终端节点架构 4.创建迁…

echarts环图配置

echarts环图配置 1、安装echarts npm install echarts4.9.02、页面引入echarts import echarts from echarts;3、应用 template片段 <div class"chart-wrap"><div id "treeChart" style "width: 180px; height:180px;" ><…

vite介绍

vite vite是一种新的前端构建工具&#xff0c;vite借助了浏览器对ESM的支持&#xff0c;采用和传统webpack打包完全不一致的unbundle打包机制&#xff1b; vite的快主要体现在两个方面&#xff0c;快速的冷启动和快速的热更新 快速的冷启动&#xff1a;vite只需启动一台静态页…

LeetCode刷题笔记【24】:贪心算法专题-2(买卖股票的最佳时机II、跳跃游戏、跳跃游戏II)

文章目录 前置知识122.买卖股票的最佳时机II题目描述贪心-直观写法贪心-优化代码更简洁 55. 跳跃游戏题目描述贪心-借助ability数组贪心-只用int far记录最远距离 45.跳跃游戏II题目描述回溯算法贪心算法 总结 前置知识 参考前文 参考文章&#xff1a; LeetCode刷题笔记【23】…

SpringBoot隐藏文件

1.设置 2.输入file Types 3.点击忽略文件或者文件夹 4.成功

Linux下go环境安装、环境配置并执行第一个go程序

一、安装 1.Golang对Linux的内核版本要求 GO对Linux内核版本最低要求是 2.6.23&#xff0c;对应要求操作系统版本是&#xff1a; RHEL 6.0CentOS 6.0即&#xff0c;不支持 (RHEL 和 CentOS) 的 (4.x or 5.x)。2.下载golang的代码版本 Golang的官网下载地址&#xff1a;https:…

Qt 简单闹钟

//wiget.h#ifndef WIDGET_H #define WIDGET_H#include <QWidget> #include <QTime> //时间类 #include <QTimer> //定时器类 #include <QTextToSpeech> #include <QDebug> QT_BEGIN_NAMESPACE namespace Ui { class Widget; } QT_END_NAMESPA…

文件上传与下载

文章目录 1. 前端要求2. 后端要求 1. 前端要求 //采用post方法提交文件 method"post" //采用enctype属性 enctype"" //type属性要求 type"file"2. 后端要求 package com.itheima.reggie.controller;import com.itheima.reggie.common.R; impo…

(数字图像处理MATLAB+Python)第十二章图像编码-第三、四节:有损编码和JPEG

文章目录 一&#xff1a;有损编码&#xff08;1&#xff09;预测编码A&#xff1a;概述B&#xff1a;DM编码C&#xff1a;最优预测器 &#xff08;2&#xff09;变换编码A&#xff1a;概述B&#xff1a;实现变换编码的主要问题 二&#xff1a;JPEG 一&#xff1a;有损编码 &am…

README

一、Markdown 简介 Markdown 是一种轻量级标记语言&#xff0c;它允许人们使用易读易写的纯文本格式编写文档。 应用 当前许多网站都广泛使用 Markdown 来撰写帮助文档或是用于论坛上发表消息。例如&#xff1a;GitHub、简书、知乎等 编辑器 推荐使用Typora&#xff0c;官…