数据库管理173期 2024-04-22
- 数据库管理-第173期 OceanBase一体化Plus多模融合(20240422)
- 1 架构简化
- 2 不止融合
- 2.1 行列混存
- 2.2 多维使用
- 2.3 多模JOIN
- 3 展望
数据库管理-第173期 OceanBase一体化Plus多模融合(20240422)
作者:胖头鱼的鱼缸(尹海文)
Oracle ACE Associate: Database(Oracle与MySQL)
国内某科技公司 DBA总监
10年数据库行业经验,现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星,ITPUB认证专家、专家百人团成员,OCM讲师,PolarDB开源社区技术顾问,OceanBase观察团成员
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号,非著名社恐(社交恐怖分子)
公众号:胖头鱼的鱼缸;CSDN:胖头鱼的鱼缸(尹海文);墨天轮:胖头鱼的鱼缸;ITPUB:yhw1809。
除授权转载并标明出处外,均为“非法”抄袭
本次《2024OceanBase开发者大会》,发布了OB4.3,在单机分布式一体化架构的基础上,大幅提升了AP能力,同时着重宣传了多模融合功能,那么多模融合到底能解决什么问题,带来什么展望。
1 架构简化
这里我调用一下我周五的PPT:
在单模多类型数据库的架构中,除去关系型数据库,可能还需要:
- Redis:作为常用简单常用数据的缓存,加速相关信息读取性能,源数据一般来自于关系型数据库
- MongoDB:用作非关系型JSON数据存放,有一定的分布式加速能力
- ElasticSearch:作为搜索引擎用于较大规模近实时搜索查询,源数据一般来自于关系型数据库,虽为JSON存储但一般遵循关系型模式
- ClickHouse:宽列/列式存储,用于联机分析处理,实现实时查询
- Hadoop:汇聚并清洗来自于各处的数据,并进行大规模离线数据分析
- …
在这种架构下,会有一些问题:
- 每一种数据库需要独立的运维能力
- 每一种数据库有单独的学习成本、应用规范
- 获取结果往往需要应用层组合多类型数据库获取数据,代码复杂
- 各数据库之间数据流转繁杂,大量依赖网络,而网络是现代IT架构最不稳定的因素之一
- 同一份数据在不同数据库之间存在大量重复,不仅有存储浪费的现象,还有全局一致性校验的压力
- …
那么多模数据库,至少单从数据模态整合到了一个数据库中能实现些什么:
- 仅需维护一个数据库,DBA/Ops省下来的时间可以出去晒太阳
- 应用仅需配置到一个数据库,Dev不用管一堆配置串
- 各类型、模态数据在一个数据库内流转,交互更加便捷,敏捷老板很开心啊
- 数据冗余少,给业务省点钱
- …
但融合数据库仅仅只带来了数据架构层的简化么?
2 不止融合
2.1 行列混存
随着业务场景和数据库技术的发展,数据库需要实现OTLP的基础能力,OLAP要求从Offline不断向Online
一份数据,通过行存方式保持OLTP性能,通过列存方式实现在线数据分析能力,二者组合,让一套数据库实现实时事务交易与分析HTAP能力。OB 3.x时代其实说了很多的HTAP场景,有了行存、行列混存。我个人觉得那时候OB说的行列混存,其实是工程上的概念和实现。其实用户需要一个更广义的、用户视角的“行列混存”,一个数据库里技能行存、又能行混存、还能列存,不同业务场景用不同的列存选择。这次在4.3发布,我终于看到了,在这个版本中行存列存甚至可以在表级来制定。
2.2 多维使用
在一个多模数据库中,不仅可以使用原单一模态专用数据库熟悉的方式对对应模态的数据库进行使用,减少学习成本与代码改动;也可以使用创新的针对多模数据的SQL语句方式,对不同模态的数据进行使用。
2.3 多模JOIN
多模融合数据库带来的还有不同模态的数据不再存放在各自的数据孤岛之中,在一个数据库内可以直接将多模态数据JOIN在一起,省去了不同数据库之间的数据交互,减轻了网络负载,统一了多模数据库使用方式。
最终,OceanBase希望通过分布式(包含单机分布式一体化)+多模融合数据库,实现强劲的事实分析数据库能力。
3 展望
在本次《2024OceanBase开发者大会》上,OB也公布了2024的路线图:
AP领域有很多优秀的数据库,过去十几年里用户都玩的很转。这块OB的定位和思考也很清楚,不做数仓只做数据库,不做超大数据体量只做PB级,解决实时分析场景的问题。话说如果实时分析能解决,离线还会难吗?OceanBase必将越来越好。最后总结下,业内多模是小卷,AP是真卷,欢迎OB加入卷王队列,卷出用户喜闻乐见的新高度!