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

也说说关于Stonebraker颠覆式数据库设计的感受

数据库杂记 2023-12-29
114


也说说关于Stonebraker颠覆式数据库设计的感受

前几天,一篇文章:80岁Postgres创始人、数据库领域“祖师爷”想颠覆数据库设计:不推翻下当前技术,不足以谈人生, 确实也引起了广大数据库爱好者的兴趣和相关思考。

关系数据库自70年代以来,其基本理论基本成型。相关的几位图灵奖获得者:

  • Charles W. Bachman,他还不是关系数据库领域的开拓者。他是网状数据库IDS的开拓者。号称网状数据库之父。73年获图灵奖。

  • Edgar F. Codd,提出关系数据库,正所谓关系数据库理论基础。1972年,他提出了关系代数和关系演算,为日后成为标准的结构化查询语言SQL 奠定了基础。号称关系数据库之父。81年获图灵奖。

  • James Gray,  解决保障数据的完整性、安全性、并行性,以及从故障恢复方面发挥了十分关键的作用,提出并实现数据库事务处理。事务处理技术上的创造性思维和开拓性工作,使他成为该技术领域公认的权威。而事务处理也是数据库系统实现当中的最核心的部分之一。98年获图灵奖。

  • Michael Stonebraker, 就是本文引文中提到的主角。创造了数据库系统一系列奠基性基本概念和实际技术。Ingres,  Postgres,  Informix, Sybase (MS SQLServer)等一众数据库的起源,都直接或间接有他的主持或影子。

基本理论,这四个人的成就基本上也就成型了。这几十年这个领域的发展,应该更多的体现在数据库实现方面的各具特色。

这么多年以来,我们一直很直观的接受了数据库系统底层依赖于操作系统的实现,毕竟它的所有资源的管理可以通过“受控”的操作系统的相关API调用,得以最终实现。有的数据库(产品)可以实现的时候,“受控”影响严重些,有的“轻”些。

以表与物理文件之间映射关系为例 ,当前很多数据库系统,大到大型商用数据库Oracle、DB2、Sybase/SQLServer,小到嵌入式SQLite、Sybase ASA等,使用的都是用一个物理文件去放置多个表,甚至一个数据库就完全放到一个大文件或串接几个数据文件来进行统一管理。这种实现的好处就是,不需要那么多物理文件来表示系统中的所有表了。可控能力强了。有些数据库为了提高读写性能,甚至支持对裸设备(文件)的直接读写,基本上算是跳过操作系统层了。

PostgreSQL和MySQL的早期的MyISAM引擎,使用的是一表多文件实现方式,从实现角度来讲,相对直观,没那么复杂。但是受制于操作系统太多,最后能支撑的表的数量(性能可控的基础上)还是大受影响的。

这是以表在文件中的物理表示作为例子,在内存分配与使用调度上,同样,也存在这样或那样的不同。在文件的I/O处理上,是否能越过操作系统管控,尽少交互次数,减少用户态与核心态切换的次数,都是影响与制约系统实现的因素。

从前,DB依赖于OS,底层的”屁股“肯定是往OS这边倾斜,所有的底层API都受OS制约控制。一旦发生反转,先有了DB,基于DB的”原语“来定义实现操作系统 ,仍然离不开”抽象”。操作系统的那一套要全部通过DB的底层接口来定义和实现。好处是什么,“屁股”彻底倒向DB了,一切以它为中心。 可能好玩的地方在于,新的操作系统的外部展现:

  • 文件系统,可能元信息就存在数据库的一两张表里头,支持快速树状查询与更新

  • 内存,进程之类,全都通过表或视图来定义

  • 用户管理,数据库用户等于高于操作系统用户?

上边这些还只是展现给用户的外部使用接口。以前是OS独立实现的,有了DB做底层以后,可以在依赖于数据库的基础上,实现出来 。但是更底层的抽象,线程,进程,内存,设备驱动等,应该还是独立的,只是那些东西不再跟OS紧密绑定,而是优先给DB使用和控制,OS再在这基础上实现。如果是这样,数据库系统肯定能得到最好的资源利用率。

说到这儿,穿插几个小故事:

(1)很多年前,实验室做基础地图展示(显示),使用C++来存储处理所有几何对象,都是一个个new操作初始化出来的东西,然后迭代循环遍历,显示。咱们中国地图基础数据也大,最后可想而知,性能是很差的。因为这里边的new操作,都用的是缺省的内存分配行为。但是C++可以自定义global new操作符,你可以一次性的把系统要的内存直接malloc出来,然后再分配给那些对象。一下子性能就上去了。上百倍的提高。

(2) Java里头的文件读写,逐字节读写,分块读写,带Buffer的分块读写还有使用NewIO的读写方式,性能各部相同。

(3) SAP过去有些客户,在使用HANA的过程中,有时候发愁,犹豫,要不要单买处理xml/json Document Service的别家的产品,要不要单买ESRI的GIS类空间处理的引擎,要不要单独弄一个WebServer之类的,要不要单独集成一个类似于R语言的分析引擎,结果发现HANA把那些功能都做进去了。完成做在怦台化了。

说这些,是想表明一个观点,越能底层把控那些资源调度和处理,你就越有可能实现一个高性能的产品。前提是,原有系统是否具备这个条件。

Stonebraker老爷子的设想,确实是跨度很大,但是,这种”架构“上的调整,还是底层基础软件的依赖关系的调整,实现一套出来,所要的人力和时间,无疑是很大的。不知道哪些厂商会去挑战这个设想。极有可能的是,这个老爷子会在院校的实验室搞出一个原型,然后优化和孵化,再商业化。毕竟,他不是第一次干这种事情。

参考:

https://mp.weixin.qq.com/s/NCqcDvcmXarp3UT1vG80-Q [https://mp.weixin.qq.com/s/NCqcDvcmXarp3UT1vG80-Q]



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

评论