大家好,我是考100分的小小码 ,祝大家学习进步,加薪顺利呀。今天说一说下一个十年,开发者需要什么样的数据库?[通俗易懂],希望您对编程的造诣更进一步.
首先,请每个人用一句话和三个标签进行自我介绍。
我的第一个标签是“工程师”,我是一名开发者;
第二个标签是“一体化”;
第三个标签是“性价比”。
(后面两个是 OceanBase 的特性)
我的第一个标签是 DBA,曾是阿里员工;第二个标签是创业者,现在我正在创业,做数据库基础设施层的产品;第三个标签是“一体化”,我们将数据库、软件、硬件做成一体化的方式,提供开箱即用的解决方案。
我的第一个标签是DBA,从业多年,经历了从 Oracle、MySQL,再到现在分布式数据库等阶段。第二个标签是技术社区,我现在参与 dbaplus 社区的建设工作;第三个标签是技术分享,我平常喜欢写技术文章,曾出过两本数据库技术的书。
我最重要的标签是 PostgreSQL 本身,因此第一个标签是 PostgreSQL,第二个是开源社区,第三个是布道师。哪里有 PostgreSQL,哪里就有我。
针对 OceanBase 最新提到的“单机分布式一体化”一词,在大众印象里“单机”与“分布式”是割裂分开,为什么 OceanBase 会将他们组合起来?
2021 年底,我们开始分享 OceanBase 一体化的概念,当时称为“集中分布式一体化”,但这个说法并不直观,后来改为“单机分布式一体化”,代表 OceanBase 将两类系统产品特性和技术优势融合在一起,它的特点是既可以像单机数据库一样使用,又拥有分布式数据库无限水平扩展的能力,对开发者友好。
如果将一个分布式系统当做一个单机系统来用,部署到一台机器上的话,性能将大幅度降低。如何突破该瓶颈,OceanBase 有什么独门秘籍?
早期支付宝有很多 Log,DBA 总结的规律是当 Log 打开强同步时,性能会降低 35%。为什么分布式应用到单机会出现性能损失?因为分布式要做高可用、强同步的容灾开销。
对 DBA 来说,从单机到分布式一体化,具体涉及到哪些操作的变化?对系统有什么样的影响?
在单机分布式一体化理念下,首先要求开发者对 DBA 是透明的,扩容操作由数据库后台实现,对以前的业务及应用协议没有影响。虽然数据库扩容,但可通过动态路由来自动找到机器原始数据。因为底层架构是分布式,所以扩容后是全部支持上层功能的。而原来单机的产品无法做一体化的原因是原来的 SQL 引擎是为单机设计的,换成多机的话很多功能支持不了。
我非常认同 OceanBase 对单机场景的关注。从我接触的用户需求来分析,单机场景更为大众化。因为对于大部分的企业用户而言,可能单机已经足够业务所需。如果一上来就用分布式系统,那么门槛相对较高。技术是相辅相成的,在“软硬一体化”趋势下,硬件发展核数越来越多,可扩展性的内存、吞吐足够大,结合硬件能力,再加上数据库在单机上性能开销的优化,未来在大众化场景的适用面、接受度将更强。因此我认为,OceanBase 往单机的思路上走是很友好的。
开发者提到分布式数据库,认为它的使用门槛较高,因此我们希望通过一体化架构来降低门槛。回答您的问题,我们更多考虑如何从单机怎么扩展到多机的使用场景。在 OceanBase 单机分布式一体化架构下,企业业务从小到大扩展的过程中,无需重写应用。OceanBase 不仅有效帮助企业降低成本,又有面向未来的拓展能力,相信未来它的应用场景将越来越广。
站在用户的角度来看,OceanBase 将方便留给用户,把麻烦留给自己。如果从数据库的设计角度来说,想必投入巨大,其中 ROI 如何评估?
ROI 是 OceanBase 做单机分布式一体化架构设计时非常重要的关注点。OceanBase 从最开始做分布式数据库,再到现在对单机的优化,这本来是我们要做的事情。
OceanBase 从分布式数据库开始已经做了 13 年,如今从分布式到单机,居然比传统的单机数据库 MySQL 性能还要好,OceanBase 是如何做到的?
OceanBase 的存储引擎与 MySQL 相比,有两点优势:一是因为 MySQL B+树做得早,OceanBase 的引擎是在尊重经典架构的基础上全新设计,存储成本会更低,单机数据库基本很少在线压缩,但是我们可以在 OLTP 业务里做在线压缩。二是在内存里实现大部分高频操作,最终才能在引擎层做到性能好、成本低。
其实在国内做数据库是一件幸福的事情,因为中国企业的业务场景复杂,存在一些机会。
辉:
中国企业有不同的场景需求,比如运营商的数据查询复杂、高并发,很过国内数据库厂商的 复杂查询诉求从运营商场景来的,产生了很大的帮助。
在过去十年时间里,中国应用场景的发展是全球领先的,尤其像阿里双 11 的极端挑战。我原来在 Sybase 公司工作时,那时候大家认为数据库的顶级挑战来自华尔街,只要解决了华尔街的问题,那么其它问题就能解决。但是在 2010 年前后,我们发现不知道如何解决双11这一量级的问题,这是 OceanBase 最早解决的问题。
是的,应用驱动技术创新。当前 OceanBase 在某些方面已超 国外主流数据库,坦诚说还有好多地方没有超越。但 OceanBase 积累了全球用户丰富场景以及对较罕见场景的解决方案,是其它数据库达不到的。
每个人都做过开发、DBA,在各位看来,开发者最喜欢什么样的数据库?
我认为功能丰富、简单好用的数据库是开发者喜欢的。
我们社区做过开发者对于分布式数据库的调研,提炼出“4+1”模型,大家对于分布式数据库的选型有四个点:一是切入点,对于分布式数据库的选型要求先是稳定性,其次是可扩展性。二是对硬件成本、研发接入使用成本要尽量低。三是对产品的功能、易用性比较关注,尽可能跟主流的技术栈可以兼容。四是很多公司有多种技术栈,开发者希望能对 SQL 协议兼容,让研发接入更简单。这点 OceanBase 相对来说,是有优势的。
随着业务越来越复杂,用户会倾向于不同业务场景的解决方案,在该细分的业务场景有没有数据库来解决,因此部署越来越多类型的数据库将可能成为企业的常态,但很难说有一款数据库可以解决全部场景问题,如图、时序、向量、多模态等,OceanBase 是怎么看待这个问题?
OceanBase 攻坚 HTAP 能力。今天 HTAP 还做不到将离线分机的问题全给解决掉。未来,HTAP 可能会在 OLTP 加上在线分析,但如果是图这类的场景不一定完全适合,要基于HTAP 做 Key Value、多模等,一个套件里有多个产品,一次性解决分布式、高可用等问题,避免额外的研发投入。
您这边是站在数据库的视角来观察,从我的视角来看,为了解决用户对数据库选型的问题。我们提供一个数据库 PaaS 平台,支持十几种数据库的全生命周期管理,这也是一种解决方案。
是的,这个方式也是非常好。只要能满足用户需求的解决方案,理论上都是合理的,而且会共存的。
数据库的发展不仅靠厂商,而是厂商+生态+开发者+用户+应用场景携手发展。
刚才提到 HTAP,据统计,中国有近 260 个数据库品牌,涵盖很多 HTAP 数据库。在 OceanBase 提到的“HTAP”含义,和广泛意义上大家提的 HTAP 是否有不同的地方?
我将 HTAP 分成三类,第一类是将 OLTP、OLAP 一套做并集。第二类是做交集,对于本身 TP 能力和 AP 能力都比较弱的场景,交集来做大家都没有覆盖的场景。第三类是 OceanBase 自然衍生的思路,像 OLTP 加上 OLAP 成为 HTAP 系统应用的核心,假如连应用的核心能力都没有的话,这种 HTAP 不是真正的 HTAP。
有的数据库 AP 强补足 TP 的能力,这是合理的路径吗?
只有从TP开始才有可能成功,TP的门槛很高,涉及到核心场景。如果将核心场景做好了,往 AP 是自然延伸,相当于由高到低,如果 AP 做好了,本身 AP 的重要程度、核心程度远远低于TP,别人不会因为选了 AP 而选 TP。
Oracle 也是这样的思路,把 TP 做到极致,同时拥有部分 AP 能力、离线能力。OceanBase 后续的 roadmap 非常巧妙,拿出一个副本做列存,既升节空间,又做到数据的一致性,不需要单独设计一个表格,我十分期待这个功能。
Oracle 是 HTAP 数据库,但在列存方向上 Oracle 有 In Memory 特性,有空间换时间的实现方式。OceanBase 是如何实现的?
Oracle 是 IMC 模式,不是真正的列存路线。虽然列存是更先进的方案,但 Oracle 的技术债务太大,OceanBase 没有 Oracle 那么重的技术债务,可以直接用最优的方式来实现。
回到刚才说的,真正颠覆掉 国外主流数据库的不是一个更好的 他,一定是一个更好的OceanBase。希望未来还能看到 OceanBase 为我们带来更多的创新。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/11659.html