Advanced Database Systems: History of Databases

于 2025-07-14 15:47:49 发布
阅读量275 收藏 9
点赞数 3
CC 4.0 BY-SA版权
文章标签： 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/datacreating/article/details/149332370

《Advanced Database Systems: History of Databases》聚焦数据库系统发展脉络。本文先阐述研究背景，梳理课程核心要点；再系统追溯数据库历史演进，总结关键论文的理论突破与实践价值；最后列出参考文献。通过多维度梳理，呈现数据库从萌芽到成熟的历程，为理解现代数据库系统提供全景视角。

What Goes Around Comes Around

  • 介绍了数据模型发展的 35年历史，一共有9种模型

  • 网络模型、层次模型、关系模型这几个是主导的

  • 实体关系、R++、语义模型、OO、对象关系，是对关系模型的一些补充

  • schema-last 是个很不错的补充

  • 严格机构化、严格结构+半结构、半结构、文本数据

  • 第1、第2都有很多场景，第4 用于文本信息检索

  • 第3 种场景实际不多

历史的轮回

  • 数据模型的发展历史，从复杂、到简单，简单模型最后获胜

  • 可见简单模型、逻辑-物理结构、高层级API 是非常有用的

  • 随后就是一系列的功能增强，但这些没能吸引市场，因为增加了很多复杂度，但却没能带来更多的好处

  • 比如 XML 倡导者 vs关系模型，就很像 关系模型 vs CODASYL

  • 只有 UDF，以及自定义访问方式 能吸引人注意

  • 以及 code in data base、schema last 真正新的发明

  • 大多数新发明则是对过去的模型的重新发明而已

总数据库的历史看

  • 最初是有三种形态的数据模型，网络模型、层次模型、关系模型(出现更靠后)

  • 网络模型和层次模型都有它的优点，相对于关系模型，这两个最大的问题是 逻辑数据、物理数据耦合

  • 也没有提供一种高层级别 API

  • 所以关系模型出现后，提供了一种更简单的数据结构、更高层级别API、更重要的是 物理、逻辑数据解耦

  • 很快关系模型就占据市场主导地位了

  • 商业市场的 IBM、Oracle，以及学术界的 PostGRE都相继出现，但这个时候还是商业主导

  • 之后出现了各种对关系模型的补充

  • 实体关系模型、R++模型、OO模型、对象关系模型，这些模型都不能算主导地位

2000年之后

  • 互联网的出现，使的数据库并发大增，商业数据库显得太贵了，开源 + 自研就称为主导了

  • 这时候出现了一批开源的 NoSQL数据库，他们只能解决一类问题，并对关系模型、事务做了减法

  • 这些数据库都是互联网头部公司搞出的开源产品，加上MapReduce的出现，看起来在数据库之外可能要有一条新的路线

  • 但是过了十年后，这些NoSQL还是缺乏一些基本保障、纯MapReduce 太底层了，跟最初的 CODASYL 一样是跟底层紧耦合的

  • 所以从历史看，这就是一个错误的选择，高层级 API、尽可能的抽象是数据库发展的一个必经之路

2010年之后

  • NewSQL的出现，因为有更大的业务需求，所以一定要分布式，但是关系模型还是很好用的

  • 一个大的趋势是单纯的自建Hadoop 集群成本太高，远不如云厂商的对象存储划算，在替代Hadoop 的同时，出现了存储计算分离

  • 存储计算分离之后，就是各种云数据库，有云厂商的、有独立新兴公司、以及老牌公司转型的

  • 此外基因数据库、流计算、图数据库、时序数据库、区块链数据库、向量数据库等等各种专业方向的数据库也出现了

  • 随着业务规模的变大，各种更细分主题的主题的数据库也跟着出现，他们都用来解决一些特定场景的问题，而这些特定场景的市场也不小

可能以后会有更多的数据库，但是解耦、高层级 API 应该是一个不变的主题每种数据库都会各自的解决场景，但又会扩大自己的领域，都会支持SQL，所以边界也模糊了而关系模型，SQL这种声明式语言，则又进一步增强了

参考

  • Charles Bachman

  • Culliane Database Systems

  • Paper: Derivability, redundancy and consistency of relations stored in large data banks

  • Paper: A relational model of data for large shared data banks

  • The difference between God and Larry Ellison

  • Data Cube

  • The (sorry) State of Graph Database Systems

  • Duck PGQ: Efficient Property Graph Queries in an analytical RDBMS

  • Merkle Trees

 相关文章

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

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

  • Building An Elastic Query Engine on Disaggregated Storage

  • Efficiently Compiling Efficient Query Plans for Modern Hardware

  • Generating code for holistic query evaluation

数新智能
关注
博客
Hive MetaStore的实现和优化
07-09 708
org.apache.hadoop.hive.metastore.api，这是Iface里面库、表会引用到这些RPC类，这些类的一些数据结构定义又引用了更下沉的thrift类。右边是 hive meta-store client，兼容了这个客户端协议的框架，如 spark，会通过 hive meta-store 协议连接过来。org.apache.hadoop.hive.metastore.model，将数据中的数据读取封装成对象，再将这个对象转为thrift RPC中的对象。
博客
The History of Big Data
07-09 939
从 2003 年分布式系统雏形初现，到 Hadoop 掀起开源浪潮，再到 Spark、容器化技术与深度学习的接力革新，以及 Hadoop 生态的兴衰起落，大数据发展史如同一部技术进化史诗。新的 Hadoop 调度框架 Yarn 出现之后就是 Spark 的崛起，对整个行业有巨大的推动基于Sarpk 创建了Databricks，他们是基于云的，而不是搞发型版本。公司更多是缺乏熟练的劳动力，他们更愿意花钱迁移到新方案而不是优化，可能因为低效的数据管理，使的企业会寻找更好的方案，类似Hadoop的新周期又诞生。
博客
Presto在B站的应用
07-04 640
gateway 会解析SQL，替换表达式提取通用 MD5特种，如果类似的请求出现，会做拦截，或者kill。监听发布系统kill -15信号，将自身状态改为非 activ，等完成任务再退出，实现无损发布。查询结果做 MD5提取，放到redis，如果有DDL事件，根据分区，做缓存失效处理。资源隔离方面，使用了 lable，根据已经配置好的lable，动态选择对应的集群。多表在不同机房，路由到数据量较大的表所在机房，较小的表限流读。对 query 做解析，根据依赖的表和分区，选择合适的机房。
博客
亚马逊云科技中国峰会：数新智能CTO原攀峰详解一站式AI原生数智平台DataCyber在Amazon EKS的实践
07-01 861
6月20日，在上海世博中心举办的亚马逊云科技中国峰会 “在 Amazon EKS 上运行高性能生成式 AI 应用” 分论坛圆满结束。本次分论坛聚焦于 Amazon EKS 在生成式 AI 应用领域的强大支撑作用，数新智能CTO原攀峰凭借其深厚的技术背景和丰富的实践经验，为现场观众带来了一场精彩绝伦且极具深度的演讲。
博客
《深入浅出Apache Spark》系列⑤：Spark SQL的表达式优化
12-16 1168
随着数据量的快速增长，传统的数据处理方法难以满足对计算速度、资源利用率以及查询响应时间的要求。为了应对这些挑战，Spark SQL引入了多种优化技术，以提高查询效率，降低计算开销。本文从表达式层面探讨了Spark SQL的优化手段，重点分析了三个方面。
博客
《深入浅出Apache Spark》系列②：Spark SQL原理精髓全解析
11-07 1595
本期是 DataFun 深入浅出 Apache Spark 第二期的分享，主要介绍 Apache Spark SQL 原理，包括：Apache Spark SQL 基本概念、Apache Spark SQL 核心组件、Apache Spark SQL API
博客
《深入浅出Apache Spark》系列③：Spark SQL解析层优化策略与案例解析
11-07 1077
本系列是Spark系列分享的第三期。第一期分享了SparkCore的一些基本原理和一些基本概念，包括一些核心组件。Spark的所有组件都围绕SparkCore来运转，其中最活跃的一个上层组件是SparkSQL。第二期分享则专门介绍了SparkSQL的基本架构和原理。从第三期开始，后续的分享都围绕着SparkSQL展开，尤其是SparkSQL的优化。
博客
Spark SQL分析层优化
09-27 1503
导读：本期是《深入浅出Apache Spark》系列分享的第四期分享，第一期分享了Spark core的概念、原理和架构，第二期分享了Spark SQL的概念和原理，第三期则为Spark SQL解析层的原理和优化案例。本次分享内容主要是Spark SQL分析层的原理和优化的案例，且此优化案例是对于理解分析层原理很重要的。本期介绍会围绕下面五点展开： 前情提要 Spark SQL 分析层原理 优化案例 总结 Q&A ►►►前情
博客
Flink优化之--旁路缓存和异步IO
08-29 1137
在异步模式下，单个并行子任务可以连续发送多个请求，按照返回的先后顺序对请求进行处理，发送请求后不需要阻塞式等待，省去了大量的等待时间，大幅提高了流处理效率。默认情况下，在Flink 算子中，单个并行子任务只能以同步方式与外部系统交互：将请求发送到外部存储，IO阻塞，等待请求返回，然后继续发送下一个请求。这就是flink的简单优化，综合来看，旁路缓存和异步IO的引入不仅解决了传统计算中存在的瓶颈问题，还为系统的可扩展性和稳定性提供了坚实的保障。堆缓存，性能更好，效率更高，因为数据访问路径更短。
博客
Patch-Package：一款灵活的开源依赖修复工具
08-27 1495
它让我们能够在不破坏原有开发流程的前提下进行灵活的修改，是开源项目和团队协作中的得力助手。通过掌握 Patch-Package 的使用方法和最佳实践，你可以大大提高项目的开发效率，避免依赖管理带来的困扰。（原因是笔者对select的组件进行了二次封装，某些value的变化是在下一个 run loop发生的，而element-plus中的表单检查是线性触发的）开发者可以将开源库的源码 Fork 到自己的代码仓库中，然后在 Fork 后的仓库中进行修改和维护。开源库可能存在 Bug 或者与项目不兼容的问题。
博客
玩转生产环境全链路压测
08-13 1238
生产环境全链路压力测试（Production Environment Full-Link Stress Testing）是一种针对线上系统进行的综合性性能测试方法。这个过程涉及模拟实际用户行为，从用户界面到后端数据库的整个应用链路上施加预定的高负载，以全面评估系统在接近或超过预期峰值流量条件下的性能表现和稳定性。意味着测试不仅仅局限于某个单一模块或服务，而是涵盖从用户请求发起、前端处理、业务逻辑执行、数据库操作直到最终响应的整个流程。这样可以确保所有组件在高负载下的协同工作情况得到验证。
博客
DATAX自定义KafkaWriter
08-13 1657
可以注意到上文中的Task内部类中定义了几个特殊的变量：recordHeaders、cdcValue、primaryKeys，这几个变量主要是用来定义特殊的kafka消息格式，比如当前代码的逻辑是要将消息转换为CDC相关的格式，所以做了额外处理。可以参考该思路，如果有其他的类似的需求，也可以通过任务配置传递进来，然后构建消息的时候进行处理。该类为我们实现写入数据到kafka的主要逻辑实现类，其主要结构可以参照上文中提到的datax官方文档，代码示例如下，每个地方的处理逻辑可以参考代码中的注释。
博客
Spark内核的设计原理
07-22 989
同时Spark有任务级别的内存管理，任务的计算属于执行内存的一部分。包括检查点支持，易于使用（支持Java，Scala，Python等编程语言），交互式（Spark Shell）和SQL分析（借鉴了ANSI SQL等标准的实用语法和功能），批流一体，丰富的数据支持，高可用，丰富的文件格式支持。DAG调度（DAGScheduler）负责创建Job，将DAG中的RDD划分到不同的Stage，给Stage创建对应的Task，抽象成Taskset，并将Taskset批量提交给TaskScheduler。
博客
以Zookeeper为例 浅谈脑裂与奇数节点问题
07-19 1478
因此，对于6台服务器的集群，计算过半数需要的票数为 `half = 6 / 2 = 3`，意味着至少需要4票来成功选举出一个Leader。在某些情况下，为了确保集群中只有一个有效的领导者，可以采用磁盘锁或仲裁机制。② 若网络断开，机房1内的3台服务器可以通过内部投票选出一个Leader（因为3票已经超过了5台总数的半数，即2.5向上取整为3），而机房2因只有2台服务器，无法独立选举出Leader。此外，资源的浪费也是脑裂的一个重要影响，因为同一操作可能在多个分区中重复执行，消耗大量计算和存储资源。
博客
MinIO:开源对象存储解决方案的领先者
07-05 4843
MinIO 是一款开源的对象存储系统，致力于提供高性能、可伸缩、安全的数据存储解决方案。官方解释：MinIO 是一个基于Apache License v2。0开源协议的对象存储服务。它兼容亚马逊S3云存储服务接口，非常适合于存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等，而一个对象文件可以是任意大小，从几kb到最大5T不等。MinIO是一个非常轻量的服务,可以很简单的和其他应用的结合，类似 NodeJS, Redis 或者 MySQL。
博客
Airflow任务流调度
06-17 2702
Airflow的调度依赖于crontab命令，与crontab相比，Airflow可以方便地查看任务的执行状况（执行是否成功、执行时间、执行依赖等），可追踪任务历史执行情况，任务执行失败时可以收到邮件通知、查看错误日志。在Airflow中，简单地说，task脚本是需要被一个个调起执行的脚本，DAG脚本是管理task脚本执行顺序、执行触发条件的。在Tree View模块可以查看当前DAG每个task任务的调度状态，是执行成功、正在执行、执行失败还是等待执行等，便于快速定位到执行失败的任务，重新调启执行。
博客
机器学习入门指南：Jupyter Notebook实战
05-27 1666
对于机器学习工程师而言，他们更擅长的是算法、模型、数据探索的工作，而对于工程化的能力则并不是其擅长的工作。Jupyter Notebook生成PMML文件1​​​​​​​。Jupyter Notebook生成PMML文件2​​​​​​​。PySpark Notebook建模 -折线图​​​​​​​。TensorFlowNotebook建模​​​​​​​。R Notebook建模 - 散点图​​​​​​​。PySpark Notebook建模​​​​​​​。R Notebook获取训练数据集​​​​​​​。
博客
CyberScheduler调度引擎
05-17 561
调度集群由任务转实例、实例派发、基线监控、超时监控、资源管理、资源监控、工作流调度、实例回调、基线警告、实例归档（在大规模的任务实例在长期使用中通过归档可以减少数据查询的影响）、资源调度、故障转移；异构数据源：灵活支持多种数据源：关系型数据库 12 种、大数据存储 15 种、半结构存储 6 种、NOSQL2 种(mongo、es)、消息队列 1 种(kafka);资源调度：支持租户隔离、资源组隔离、项目的简单模式、标准模式、自定义模式；任务调度：做到分布式、高可用、多集群模式，达到千万级，支持水平扩展；
博客
CyberData统一元数据服务
04-26 1266
支持基于Spark和Flink的自定义Catalog扩展机制，支持支持更大范围的数据源元数据管理能力，使Spark和Flink引擎能够访问关系型数据库，以及实现与湖仓数据源之间的跨源数据访问。通过guid快速的定位一个表或者列，例如定位元数据表列信息可通过catalogName、schema、tableName、columnName 快速定位，从而确保元数据的唯一性，避免了数据重复、冲突和混淆，更方便的对外透出统一查询元数据的能力。灵活性高，支持API自定义血缘模型，通过API快速构建血缘；
博客
数新大数据平台迁移解决方案
04-23 1618
数新网络的大数据平台迁移能力矩阵，能够有效支撑企业数据平台迁移的时效性、安全性、可靠性、稳定性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值