当前位置: 首页 > article >正文

杨传辉:云+AI 时代的一体化数据库|OceanBase发布会实录

在 2024 OceanBase 年度发布会 上, OceanBase CTO 杨传辉进行了主题为《云和 AI 时代的一体化数据库战略思考》的演讲,本文为演讲实录,欢迎阅读。

视频观看可点击:https://www.oceanbase.com/video/9001825 


各位 OceanBase 的客户、OceanBase 的用户、各位领导、各位嘉宾大家好!今天我跟大家分享的主题是《云和 AI 时代的一体化数据库战略思考》。

1、与客户同行,OceanBase一体化架构持续演进

(一)OceanBase 为什么要做一体化数据库

早在两年前,OceanBase 已在业界率先倡导并提出了单机分布式一体化架构的理念。随后,在2022年10月发布了4.0版本。时至今日,众多业界数据库厂商亦开始关注并讨论一体化架构。那么回顾两年前,我们为何会提出一体化架构的理念呢?

随着互联网、移动互联网,特别是人工智能时代的来临,数据库所管理的数据类型已从原本单纯的结构化数据,逐步转变为半结构化乃至无结构化数据。然而,客户仍期望能够利用同一套系统来处理各种不同类型的工作负载,并确保数据的一致性。客户不再希望区分哪些查询属于OLTP,哪些属于OLAP,哪些是多模,哪些是AI,而是期望能够采用一套强大的系统来满足其所有数据存储和管理的需求。

但是,一体化的客户需求,在技术实现上,面临很大的挑战。首先,因为要处理海量数据,这套数据库系统需要是分布式,而不是集中式。其次这套数据库系统需要具备海量数据的存储与计算的能力。

OceanBase 完美契合了客户需求与技术能力,所以在 2022 年首次提出一体化,并持续践行一体化理念。

(二)践行一体化理念,OceanBase 架构持续演进

OceanBase 持续演进一体化能力,迄今为止共经历了两次大的技术迭代。从分布式到一体化,从 TP 到 HTAP,再到 SQL + NoSQL、SQL + AI。

第一次技术迭代是 1.0 版本,实现原生分布式架构下所有的节点可读可写,且单点故障下不丢失任何数据,实现真正意义的原生分布式。

第二次技术迭代是 4.0 版本,在业内首次提出并实现单机分布式一体化架构,用一个系统满足每一个用户从小到大全生命周期数据存储与管理的需求。

基于分布式和单机分布式一体化架构,OceanBase 支持各种数据库的功能,2.0 版本主要用于 OLTP mission critical,核心业务场景接入 MySQL;3.0 版本进一步增强了对实时 OLAP 的支持,即 HTAP;4.2 版本打造 SQL+NoSQL 的综合能力;4.3 版本面向  AI 时代的技术趋势,提供 AI 的融合查询能力。

2、OceanBase一体化数据库解析

OceanBase 一体化数据库主要包括 3 个层面的含义:一体化架构、一体化引擎和一体化产品。

最底层的是一体化架构, 包括单机分布式一体化和多云原生。我们希 OceanBase 一体化数据库既能应用在大企业,也能应用在中小企业,甚至是创业公司。我们希望 OceanBase 可以在业界所有主流公有云平台多云共生,应用于专有云、混合云等各种不同的部署环境,屏蔽掉不同云基础设施差异,保障数据一致性体验。

OceanBase 一体化架构之上是一体化引擎,包括一体化存储,一体化 SQL 引擎和一体化事务。一体化产品包括 HTAP 混合负载处理、SQL+AI 向量的产品、SQL+NoSQL 多模的产品等。

(一)打造一体化架构的基石:单机分布式一体化

单机分布式一体化架构是一体化数据库的基石。分布式数据库首先是用来处理海量数据,它的扩展性比较好,解决了数据规模问题;它的成本比较低,可以极大降低存储成本;它也有比较强的容灾能力。集中式数据库发展时间比较悠久,生态和单机性能非常出色。我们通过单机分布式一体化架构,融合分布式和集中式的双重技术优势,使得同一个系统既能处理数据规模的问题做到很好的扩展性,同时也能提供很好的单机功能和性能,并且像原来的集中式数据库一样,在各种中小企业中间非常通用和普适。

(二)从 TP 到 TP + AP,迈向多工作负载一体化

OceanBase 最早用来处理 OLTP 核心交易场景,从 OLTP +OLAP 乃至 HTAP, OceanBase 经历了三个发展阶段。

第一个阶段是 OLTP +。在保险行业和运营商行业,核心系统具有非常高的并发量,每条 SQL 查询非常复杂,高并发复杂查询相当于 OLTP +,对数据库的底层要求比较高,需要存储引擎能力支持行列混合负载,需要有很好的优化器。OceanBase 通过 OLTP +的方案解决核心场景需求。

第二个阶段是 HTAP。在 OLTP 的基础上引入了对实时 AP 的支持,需要用到原来的行列缓存,也需要列存索引来加速 Operational OLTP 在实时 AP 的能力。

第三个阶段是实时 AP。我们需要通过列存副本的方式,把 AP 的性能做到极致。HTAP 往往在泛互联网的场景应用广泛,正是由于这些场景对实时分析的要求更高。

山东移动是非常典型的 OLTP +的复杂查询场景。山东移动原来使用集中式数据库 Oracle,性能高且扩展受限。通过将数据库系统平滑升级至 OceanBase 后,实现 RPO=0,业务处理的效率提升近 30%,在某些场景下,存储成本降低 90%,只有原来的 1/10。

海底捞原来使用两个不同的系统分别处理 OLTP 和 OLAP。OLTP 是类 MySQL 云原生数据库,OLAP 是云原生数仓,由于 OLTP 和 OLAP 之间存在数据延迟,两个系统既无法保证数据一致性,也需要两份数据存储成本。通过将类 MySQL 云原生数据库+云原生数仓迁移到 OB Cloud 后,实现一份数据两份收益,整体成本降低 30%,同时 AP 性能比原来的云原生数仓提升了 35%。

某全球知名跨国消费品巨头的实时营销场景原来使用多套数据库系统,通过阿里云上的云原生数仓做数据处理,并且把处理结果以 T+1 的方式批量导入到 ClickHouse 做在线查询。这种方式带来两个问题:第一,数据链路复杂,数据一致性难以保障;第二,多份数据多份成本。通过将云原生数仓加 ClickHouse 迁移到 OB Cloud 之后,一份数据多份收益,且在线查询性能提升 40%。

(三)从 SQL 到 SQL + NoSQL:迈向多模一体化

OceanBase 是分布式架构,解决了数据的规模扩展性问题,所以越来越多的用户选择将 OceanBase 应用在 Key Value 存储场景,也选择用 Key Value 存储场景替换 HBase、Redis 等场景。

通过将 Hbase 替换为 OceanBase,可以解决困扰 HBase 已久的 Java 导致的性能抖动的问题,帮助 HBase 用户进一步降低成本。通过把 Redis 迁移到 OceanBase,解决了 Redis 只能使用内存而导致的高成本问题。

同时我们也在不断顺应需求,增加对 JSON、文档型、多种数据模型的支持,让 OceanBase 成为多模一体化的数据库。

(四)SQL+AI 理念:一体化让 AI 像数据库一样通用

AI 是未来的核心趋势,迄今为止,业界主流的 AI 应用大多集中在面向 To C 场景的聊天类应用。接下来的挑战在于,如何把 AI 大模型技术,用更低成本、更易用的方式,广泛应用于各个行业。

其实 IT 行业已经有一个先例,那就是数据库。数据库是 IT 行业所有基础设施里应用最为广泛的软件,我们可以将数据库理念与 AI 理念相融合,让 AI 像数据库一样好用。

3、现场跑分,验证OceanBase的向量能力

向量数据库有两种实现方式:第一种,做完全独立的向量数据库;第二种,在通用数据库里集成向量插件。毫无疑问后者一定会成为未来的趋势,通过在通用数据库里集成向量插件,能够直接复用通用数据库已经有的功能、稳定性和生态。

通过在 OceanBase 一体化数据库里面的插件,能够直接复用 OceanBase 的一体化多云原生架构能力,直接复用 OceanBase 高性能、低成本的存储和事务的引擎,直接复用 SQL,并且扩展 SQL,支持成为 SQL+,同时支持 OceanBase 已有的 SQL 能力。

有了 SQL+AI 一体化,可以帮助各个行业用户大幅简化原来的技术栈。今天很多行业用户都在做自己的智能体,智能体 AI Agent 底层涉及到各种不同的数据源,有可能是结构化的数据、有可能是文档、有可能是向量。

有一种是采用不同的数据库存储处理不同的数据类型,这种方式导致需要涉及到不同的技术栈,业务架构非常复杂,对研发人员要求非常高,不同的数据库之间还涉及到互相之间的数据传输与转化。每一次 AI Agent 查询会涉及到在同类型的数据库里查找数据,无法很好地执行查询下压。

通过一体化数据库的解决方案,可以用一条 SQL 实现对结构化数据、向量数据、地理信息数据的全方位的 Hybrid Search,帮助客户真正简化技术栈。

我认为,在未来的 AI 时代,数据库需要处理海量数据,所以未来的数据库首先是一个分布式数据库。AI 时代的数据库需要支持 Hybrid Search 混合检索,所以它也一定是一个一体化的数据库。OceanBase 一体化数据库正是为 AI 时代打造的数据底座,探讨 AI 与数据库融合的无限可能。

OceanBase 一体化数据库融合蚂蚁多年研究成果,在蚂蚁关键业务场景中长期锤炼,具有更强的性能,直接复用 OceanBase 分布式能力,将向量能力和 SQL 能力做混合搜索,实现 Hybrid Search 融入 AI 流行技术栈,支持大家熟悉的 LangChain、LlamaIndex 等。

4、两个重磅版本:4.2.5 LTS和4.3.3 GA

(一)OceanBase 4.2.5 :面向关键业务负载的 OLTP  LTS 版本

OceanBase 4.2.5 是面向关键业务负载的  OLTP LTS 版本,4.2.5 版本性能进一步提升。

TP 性能提升。在 TP 性能上,相比 4.2.1 版本,性能提升了 26%。Batch Insert 性能提升 52%,4C 小规格的读取性能提升了 37%,写入性能插入性能提升了 53%。

支持多模。4.2.5 版本新增了对多模支持、HBase 2.X 的接口,同时也有 OBKV -Redis 一体化低成本的 KV 存储服务。

提升 MySQL 兼容性。OceanBase 4.2.5 全面提升了 MySQL 的兼容性,包括基础功能、通讯协议、数据类型、语法兼容、视图、变量、生态适配等,用户可以直接将公有云上 MySQL 5.7 版本的应用数据库在不改代码的情况下平滑迁移至 OceanBase 4.2.5 版本。

4.2.5 版本同时也兼容考虑了部分海外用户的需求。在海外有很多的用户的生日是一些特别的日期,如 2000 年 0 月 0 日、2000 年 2 月 30 日,因为有些用户不记得生日,身份证上就是一些非法日期。我们对这样的数据也做了兼容性的处理。

可观测性提升。4.2.5 版本的可观测实现了全新的里程碑,对 Oracle 的兼容性进一步增强,提升了 PL 的稳定性和易用性,增强了安全能力,支持 MySQL 基于角色的权限管理,并且提供与 Oracle ASH Report 基本相当的功能。欢迎大家线下体验 4.2.5 版本!

(二)OceanBase 4.3.3 :面向实时 AP 场景的首个 GA 版本

OceanBase 4.3.3 是面向实时 AP 场景的首个 GA 版本, 4.3.3 版本相比 4.3.0 版本,在性能上有很大提升。

在性能上,相对 4.3.0 版本,TPC-H  1T 场景提升 64%,TPC-DS 1T 场景提升 36%,宽表性能 ClickBench hot-run 提升 49%,cold-run 性能提升 149%。

在功能上,4.3.3 版本大幅度完善了实时 AP 的功能,支持列存副本,进一步完善物化视图,支持物化实图增量实时刷新,支持外表集成,支持快速导入导出,支持 AP 特定数据类型,提供异步的执行功能,增强对文档检索的支持。增强 AP 场景下 SQL 诊断能力。总的来说,用户可以基于 4.3.3 版本直接构建一个 1PB 以内的实时数仓。 

4.3.3 版本是一体化的数据库,一体化多种工作负载的资源隔离能力进一步提升。一体化数据库支持不同场景,但用户很难针对不同的场景做不同的配置。4.3.3 版本提供 AP 参数模板,可以针对不同场景选择特定的模板,无需单独配置参数,即可解决所有问题。

5、多云原生:从一体化数据库到一体化云数据库

OceanBase 是一体化数据库的内核,如何成为一体化云数据库呢?最重要有三点:第一,需要有更好的云上数据库、很好的分布式能力和极致的性价比。第二,需要更开放的生态,和所有主流的公有云平台多云共生,体验一致。第三,需要有更智能的能力,通过云+AI 提升开发运维效率。

(一)分布式  + 极致性价比:打造云上更好的数据库

为了更好地打造云上数据库,首先需要一个更好的数据库内核,即 OceanBase 的内核。OceanBase 的内核是一个一体化的高压缩内核,通过多租户提升系统整合能力,帮助用户降本增效。

当我们 OceanBase 数据库内核部署到云上时,需要实现存储计算分离。OceanBase 已实现公有云上基于对象存储的存储计算分离,只要公有云平台对象存储提供符合 S3 标准的对象存储,OceanBase 就能在云上运行,并且达到极致的性价比。

(二)更开放的生态:云共生融入多云原生   拥抱云上主流技术栈

我们需要有更加开放的生态,OceanBase 和国内和国外主流云平台,包括阿里云、华为云,包括 AWS 等都做完了适配。OceanBase 正在成为所有数据库厂商里面适配云平台数量最多的产品,也是最开放的产品。

OceanBase 也在积极拥抱云上技术栈,包括开发云的框架,对主流框架的接入程度已经达到 95% 以上,包括可观测性、可运维的工具,整合和适配主流最新的 AI 生态供应链。

(三)全链路智能:将 AI 融入多云共生 提升全链路开发运维效率

当 OceanBase 与 AI 结合时,一方面 OceanBase 为 AI 应用提供支撑。另外一方面,OceanBase 也是 AI 的用户,我们需要把 AI 的能力融入 OceanBase 公有云平台,实现所有公有云共生,帮助公有云全面提升全链路的开发,包括运维设计、运维实施,甚至诊断的工具。

OceanBase 有几个工具,可以输入自然语言,也可以把 AI 融入到诊断过程中。当我们在运维过程中遇到问题,可以通过 OAS 自动诊断发现原因。OceanBase 也即将推出智能数仓 AI 工具,通过自然语言直接生成数仓里面各种各样的报表。

OceanBase 一直践行一体化战略,希望通过一个数据库满足每个企业 80% 的 OLTP、OLAP、多模、AI 等各种各样的需求,把简单留给用户。

以上就是我今天的分享,谢谢!


http://www.kler.cn/a/380116.html

相关文章:

  • 新能源汽车与公共充电桩布局
  • 《AI产品经理手册》——解锁AI时代的商业密钥
  • 【PGCCC】在 Postgres 中创建日期箱的 4 种方法:interval、date_trunc、extract 和 to_char
  • 使用正则表达式验证积累
  • 【解决办法】无法使用右键“通过VSCode打开文件夹”
  • SpringBoot新闻稿件管理系统:架构与实现
  • [LeetCode-45] 基于贪心算法的跳跃游戏 II-最少跳跃次数的求解(C语言版)
  • Meta AI 推出机器人开源项目:推动触觉感知和人机交互的前沿研究
  • 安装中文版 Matlab R2022a
  • 基于STM32的智能温室环境监测与控制系统设计(代码示例)
  • Vue前端开发:元素动画效果之过渡动画
  • selinux和防火墙
  • 音频中sample rate是什么意思?
  • 为什么 5g 物理信道 采用不同的调制方式
  • ubuntu20.04 加固方案-检查是否设置登录超时
  • 【解决办法】无法使用右键“通过VSCode打开文件夹”
  • Linux云计算个人学习总结(二)
  • 宝顶白芽,慢生活的味觉盛宴
  • elastic search查找字段的方法
  • 考研要求掌握的C语言程度(插入排序)
  • 15分钟学 Go 第 36 天:Go的反射基础
  • 【K8S系列】Kubernetes 中 Service 的流量不均匀问题【已解决】
  • 江协科技STM32学习- P34 I2C通信外设
  • 统信UOS适配C#
  • 华为配置WLAN跨VLAN的三层漫游示例
  • LeetCode 热题100(七)【链表】(1)