暂无图片
暂无图片
10
暂无图片
暂无图片
暂无图片

聊聊数据库存储架构的发展

白鳝的洞穴 2024-12-13
829

昨天和DBA PLUS社区一起搞了一场线上直播,我分享了一个主题-《数据库存储架构的演进与未来发展》。实际上这方面我并不专业,所以也只是根据我个人的经历和想法谈了一些自己的观点。

今天我先回答一下昨天大家在互动区里发的几个问题,对于一个网友问的存算分离和存算一体在数据安全性方面的区别问题,上了点岁数,当时没反应过来,实际上这个问题以前是参与过讨论的。当时说SAN网络比IP网络安全,所以存算分离架构数据更安全一些,实际上只要是网络,是软件,就有漏洞,只是一般SAN网络不暴露在互联网上,所以攻击案例少一些而已,通过服务器攻击SAN网络的案例是已经存在的了,绝对的安全不存在。真正的数据安全,在数据库领域还是需要通过全密态、主动加密等手段来解决,透明加密都是不够安全的,因为可以通过内存DUMP来获得解密数据。如果那位朋友问的是这个问题,算是我的一个解答吧。

另外关于数据库架构的尽头是RAC的问题,这是个很好的问题,当时时间有限没能展开回答,最近也遇到一些这方面的比较有趣的案例,找时间写篇文章吧。

对于数据冷热分离的问题,当时我只回答了一个方面,这个问题也很不错,这些年我也有一些工作实践,也是找时间单独写一篇文章吧。

下面正式开始今天的文章。演讲的视频回放请到dbaplus社群视频号观看。

数据库的存储架构从最早的小型机上的DAS存储到现在的分布式存储,我基本上都用过,也积极拥抱过。刚开始用数据库的几年,用DAS存储还是挺闹心的,用户也不清楚数据库和存储(当时都是叫磁盘)是个啥关系。

其实从DAS到SAN存储网络的发展还是经历了二三十年的时间的。最初的DAS就是机箱内的几块盘,磁盘柜满了就没法扩了,DEC 的VAX/CLUSTER可以通过扩集群节点的方式扩充存储容量,当时是极为先进的。后来有了外接扩展柜,刚开始的时候内置盘可以做RAID,外接扩展柜连RAID卡都没有,用起来不方便。后来的磁盘柜带RAID卡了,不过一条SCSI总线上可以接的柜子总数是有限制的,总的IO吞吐能力也受限。幸亏那时候的数据库都很小,CPU都刚刚从16位迈入32位,GB级存储都是让人仰视的。大型SAN网络的出现让一切都发生了变化,64位系统的普及也让数据量从GB级迈入TB,很快进入PB级别。

广义上讲,数据库的存储引擎不仅仅是底层存储那点事,包含了很多层面的东西:
  • 数据存储:将数据物理地存储在磁盘或其他存储介质上。
  • 数据检索:根据查询条件快速高效地检索数据。
  • 数据更新:处理数据的插入、更新和删除操作。
  • 事务管理:保证数据的一致性和完整性,通过支持事务实现原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability),即ACID属性。
  • 并发控制:在多个用户并发访问时保证数据的一致性和完整性。
  • 数据备份和恢复:支持数据的备份和恢复,保障数据的安全性。


因为时间关系,无法展开对整个数据库存储引擎进行阐述,因此今天的内容还是集中在数据库存储架构上。

Oracle基于SLOTTED HEAP的存储架构对现代数据库影响深远,其基本架构在20多年前已经趋于成熟,Oracle 7奠定了今天Oracle的块结构。而其段页式结构已经沿用了四十多年了。

很多人可能会说Oracle的存储架构太老了,已经过时了。其实不然,Oracle在数据库存储架构上的创新在持续不断地向外输出。无论是ASM技术还是Oracle Exadata,都引领了数据库存储架构的创新发展。分布式存储、软硬一体化解决方案,计算卸载到存储侧,让数据库的瓶颈被彻底打破。这是目前最为成功的一体机解决方案。

进入信创时代,可能很多用户已经无法享受到Oracle一体机强大的能力支撑了,不过国产化一体机厂商得到了发展的机会。上图的沃趣Oceanbase数据库一体机就是沃趣和OB两个国内厂商之间紧密合作的结晶。

我们从历史的角度来看看数据库存储存算一体和存算分离这两种技术路线的发展脉络。最初我们没有选择,只有存算一体这条路,那时候连C/S架构都没有,只有主机T/S架构一条路可走。随着大型SAN网络的出现,第一代存算分离架构出现了,我们称之为简单存算分离,这种存算分离可以提供高性能低延时以及几乎无限的存储容量扩展能力。

Oracle  Exadata开启了高级存算分离的时代,后来出现的 YellowBrick data,沃趣OceanBase一体机等都是Exadata的仿制品,不过技术水平与Exadata尚有距离。

分布式数据库可以通过横向扩展,不过分布式数据库也有存算一体和存算分离两种技术路线。而云原生数据库都采用存算分离的架构。通过自研的高性能云存储来为数据库提供负载卸载和近乎无限的IO和存储能力。

NeonDB是一个十分有趣的云原生数据库,是一种基于日志的数据库服务,使用对象存储来持久化数据。而计算层则使用十分廉价的K8s pods,有用户访问时Pod才被实例化,当长久没有访问时,pod自动销毁。这个与PG语法兼容的数据库,没有真正意义的数据文件,日志就是持久化层,写入WAL,持久化就完成了。Pageserver可以是一种高性能全闪存储,存放一些常用的数据页的缓冲。

参天则是一个比较新的国产化解决方案,很多国产数据库都在开发类似Oracle RAC的功能,架构在innoDB存储引擎上的数据库,通过简单改造,就可以具有类似于Oracle RAC的共享存储读写集群能力了,当然实际上要做好这一点并不像我说得那么轻松。RAC最困难的地方是CACHE FUSION,参天的开发者来自于华为存储部门。实际上高端存储的多控制器之间的CACHE同步技术是与Oracle RAC十分近似的。因此Cantian的架构是可以给我们很多启示的。万里开源、泽拓昆仑目前已经开展了和Cantian的合作。

针对最后一个话题,集中式还是分布式的问题,集中式数据库有三种主要的形态,主从,共享存储读写分离,共享存储多读多写。而分布式也有存算分离、存算一体和代理+计算分片三种模式。

个人的观点是,从目前数据库国产化替代中的实际情况看,分布式数据库在大多数场景下并非刚需;大型分布式数据库在一些大型企业,资金比较有保障的核心系统侧应用前景更好,但是大型企业不会将所有系统都迁移到分布式数据库;Oracle RAC这种共享存储对等读写或者共享存储读写分离的数据库与大多数用户的核心系统适配性最好。

分布式数据库在数据分片分区、应用改造、复杂多表关联查询的性能、存储过程性能、整体使用成本、运维难度上则还存在一定的问题。当然分布式数据库厂商也在不断优化这些问题。



文章转载自白鳝的洞穴,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论