Advanced Database Systems: History of Databases

数据库的发展历史,从复杂模型:网络模型、层次模型,再到简单的关系模型最后胜出,关系模型不止是简单,而且提出了物理、逻辑解耦、高层级别API;所以从1970年代开始,数据库的基本模型,发展方向是定了;后面出现了各种对关系模型的补充,但是大多数只是重复发明,除了code in database,schema last是比较新颖的发明;在这几十年内,商业数据库一直是主导,IBM、Oracle、微软一直是领导者;直到2000年互联网的出现打破了这个局面,数据库面临大量的访问,需要购买大量商业数据库成本太贵,此时开源产品就是更好的选择;同时也出现了各种对关系模型,他们的扩展性、性能都非常好,但他们不支持SQL、不支持事务,十年之后再看这些数据库多多少少都有一些局限性,于是分布式的NewSQL出现,加上云厂商的对象存储,云上数据库也成为主流;现在数据库有很多细分市场,每个主题内都有好几个玩家,这些数据库在巩固自己领地的同时,又在不断扩展自己的能力;他们开始支持SQL,增加事务,从历史角度看,声明式语言、解耦、简单模型一直是有生命力的

阅读全文

Column-Stores vs. Row-Stores: How Different Are They Really?

论文中通过行存系统来模拟列存,并将几个可能提升的关键点:延迟物化、块迭代、压缩、invisible-join,挨个拆分,并分析每种可能提升的原因和提升比例‘在行存的系统中使用垂直分区依然达不到列存性能,因为垂直分区后需要冗余存储主键,重建这些tuple 需要hash-join,数量大内存CPU开销也大;全索引如果返回的数据多hash-join压力大可能会更慢,反之可能更快;物化视图最好只需要读取部分数据,bitmap选择率高时效率会变差。对于列存:块迭代可以提升5% - 50%性能(取决于压缩)、invisible-join可以提升50% - 70%、压缩为2倍,如果数据有序可以量级提升、延迟物化提升3倍,如果将这些全部去掉,列存跟行存就差不多了;在列存中使用反规范化大宽表效果不好,增加维度表列冗余数据变多、只有大宽表的维度属性是排序高度压缩的才有效

阅读全文

Lakehouse A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics

第一代的数仓有很好的数据治理,缺点是计算存储耦合,且无法存储半结构数据;第二代的数据湖将计算存储分离,且能存储各种格式,云厂商推出的对象存储本质是差不多,不过扩展和可靠性更高更便宜,但二代需要两套系统,数据要在数仓和对象存储之间做ETL,有很多问题;而LakeHouse则试图解决这些问题,通过在对象存储之上增加元数据管理,实现事务功能,数据质量、ACID都实现了,因为是基于开放的格式,不会锁定厂商,也能支持各种场景。因为开放的格式和对象存储的延迟问题,性能和每秒事务不会很好,通过缓存系统、辅助数据结构、数据布局优化来优化性能,另外DataFream 支持SQL和 API,可以延迟处理这样可以进一步优化。目前的限制:S3的延迟、单表事务、servless;通过TPC-DS对比其他云厂商的数仓,性能和价格都很不错,还能支持传统场景,机器学习、科学分析等各种复杂场景。

阅读全文

Building An Elastic Query Engine on Disaggregated Storage

SnowFlake的一篇论文,目前的架构包含四层:中心化的服务处理端到端的查询、计算层、临时存储层、对象存储层,并讨论了设计临时存储这一层的原因,通过访问数据指标能发现,临时存储的需求变化很大,跟计算层,远端持久存储层都不同。为更好的提高利用率需要计算层跟 临时存储层解耦。调度方面包括:工作窃取、延迟的一致性hash。由于云厂商的计费方式支持到秒级别,原先的预热VM 方式不好使了需要采用共享资源的方式来支持多租户,带来的挑战是,重新设计临时存储层(这层缓存了持久数据和中间数据,扩容会影响其他租户),需要提供私有地址。三个开放问题:临时存和计算层解耦、内存-SSD-远端存储三层机制的有效管理、亚秒计费策略的共享资源架构挑战

阅读全文

What Goes Around Comes Around

Stonebraker的论文,介绍了 9个不同时代的数据模型;层次数据库IMS,以及网络数据库CODASYL,这两者都是逻辑数据、物理数据耦合,之后出现了关系模型,有了数据独立;再往后就是各种对关系模型的补充,如实体-关系模型、关系模型++、语义数据模型、OO模型、对象关系模型、半结构模型等;从中我们可以总结到:查询优化器很有用、技术的争论通常由市场和其他因素决定,简单模型比复制模型更容易实现数据独立、KISS 保持简单是很重要的、除非用户使用中出现很大问题否则他们不会买单、没有编程语言社区的支持想在语言上做改进突破很难、新技术的推广,需要标准化,或者大力度的推广、schema-last 可能只合适小部分场景

阅读全文