数据库的前世今生

【CSDN 编者按】被称之为基础软件三驾马车之一的数据库，在经历了层次型和网状型、关系型数据型库以及更加强大的数据管理功能等三个时期之后，其在未来的发展历程中还有哪些更多的可能性？

基于此，卡内基梅隆大学计算机科学系数据库学副教授 Andy Pavlo 曾于 2015 年为 CMU 计算机科学系 50 周年庆典上写下了自己对于数据库未来 50 年的构想。

在本文中，他提出了几点：关系模型对于大多数应用而言仍将占据主导地位，开发框架和数据库管理系统将更加紧密地耦合在一起，从而使所有数据库交互都透明化，SQL 仍然是与 DBMS 交互的实际语言，但人类永远都不会真正编写 SQL，将以自然语言查询相关数据问题，这将导致编程方式发生重大变化。无所不在的「物联网」意味着每个设备都能收集其环境的数据，对于新硬件，更灵活和可编程的处理结构将更为普遍，人类作为数据库管理员的角色将不复存在，DBMS 最终将完全自治和自我修复，星际设备的数据库事务将兴起，最终，「我将在 50 年后去世」。

作者 | Andy Pavlo

译者 | 谭开朗，责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

最终，我还是从事了我曾扬言不会从事的职业：成为一名教授，有自己的博客，但从不更新。我知道，距离我上次发表文章已有一年之久，我也需要给事务处理数据库系统这一开放议题撰写第三部分内容。去年在CMU发生了很多事情，我计划在项目更加完善后再在这里讨论。预告几点：

1. 我们正在开发一个新的分布式DBMS；

2. 我们正在构建一个用于测试和基准化分析的“准备启用的”大型OLTP应用程序库；

3. 我们正在创建一个在线数据库系统百科全书。

当然，还有很多并发控制和非易失性内存工作。毫无疑问，我的课外教授活动已经顾不太上了。

以下是我写的一篇文章，作为下个月CMU计算机科学系50周年庆典的一部分。我们每个教员的任务是：针对自身所在的领域，展望其在2065年的发展概况。所以，我的任务是概述数据库系统在50年后的样子。但是，在我展望未来之前，我首先花一些时间来讨论数据库的过去和现在。

1.数据库的过去

第一个数据库管理系统(DBMS)在1968年上线。IBM的IMS用于跟踪土星5号和阿波罗太空探索项目的供应和零部件库存。它引入了这样一种思想，即应用程序的代码应该与它所操作的数据分离。由此支持开发人员编写只关注数据访问和操作的应用程序，而不关注与执行这些操作和确保数据安全相关的复杂性和开销。IMS之后，在20世纪70年代早期，IBM的System R和加州大学的INGRES率先开发了第一个关系型DBMS。

第一批系统的数据库工作负载没有今天那么复杂和多样化。在这些早期的应用程序中，操作员通过终端启动事务，然后手动向系统输入新数据。此时，DBMS的预期峰值吞吐量仅为每秒数十到数百个事务，响应时间以秒为单位度量。这些早期DBMS的体系结构也基于当时流行的计算硬件。它们通常部署在只有一个CPU核心和少量主内存的计算机上。对于这些系统来说，磁盘是数据库的主要存储位置，因为磁盘能够存储比内存更大的数据，而且成本更低。

2.数据库的现在

尽管在50年后，我们使用数据库的方式发生了很大的变化，关系模型和SQL仍然是组织数据库并与之交互的主要方式。许多互联网应用程序需要每秒支持数十万甚至数百万个事务，每个事务的处理延迟以毫秒为单位。这是因为它们同时与数百万用户和其他计算机系统相连。现在，企业和组织能够从这些应用程序中收集大量的数据，他们希望分析这些数据来推断新的信息，以指导他们的决策。基于此，近年来我们看到了针对特定应用场景的专门系统的兴起，这些应用场景的性能比基于1970年代架构的通用DBMS要好得多。现在有一些DBMS旨在为联机事务处理(OLTP)应用程序快速获取新信息，还有一些DBMS旨在为复杂的联机分析处理(OLAP)程序存储大量数据。

这些较新的DBMS还利用了近年来出现的三种主要硬件趋势。首先是大内存计算机的出现，这使得现在可以部署少量的机器，这些机器有足够的DRAM来存储除了最大的OLTP数据库之外的所有数据。将数据存储在内存中可以确保DBMS能够以较低的延迟同时处理许多事务。根据我们的经验，用于现代OLTP应用程序的数据库的大小通常为几百GB。与OLAP数据仓库相比，DBMS可以管理几个PB大小的数据库。这是因为OLTP数据库存储应用程序的当前状态(例如，最近90天的订单)，而OLAP数据库存储组织的所有历史信息(例如，所有下过的订单)。因此，OLAP DBMS仍然主要存储在磁盘上，并使用一些优化，如压缩或柱状存储，以克服它们较长的访问时间。

第二个硬件趋势是从提高单核CPU时钟速度到多核CPU的转变。时钟频率已保持了几十年的增长，但现在增长已经停止，因为硬功率限制和复杂性的问题。复杂的、无序的、超标量的处理器正在被简单的、有序的、单问题核心所取代。在DBMS中利用这种增加的并行性是很困难的，因为协调数百个线程的共享数据的访问非常复杂。现代DBMS使用低开销并发控制和其他无锁技术来提高系统的可伸缩性。

第三个趋势是商品硬件的成本降低。这在云计算平台中尤为明显。现在可以部署一个大型集群，其处理和存储能力只相当于十年前的一小部分。这种变化与1980-1990年代相比，过去十年中没有共享的DBMS的数量在不断增加。

尽管取得了这些进展，但仍然存在一些重大问题，由此阻碍了许多人部署数据密集型应用程序。所有这些的一个主要主题是，数据库仍然是计算系统(例如，部署、配置、管理)的人工密集型组件。使用两个独立的DBMS分离OLTP和OLAP工作负载，以避免其中一个工作负载减慢另一个工作负载的速度，但是它需要额外的进程来将数据从系统传输到另一个工作负载。除此之外，调优DBMS以获得特定应用程序的最佳性能是出了名的困难。许多组织求助于雇佣专家来为预期的工作量配置系统。但是，随着数据库的规模和复杂性的增长，优化DBMS以满足这些应用程序的需求已经超出了人类的能力。

3.数据库的未来

在接下来的50年里，就像之前一样，我们将看到数据库领域的重大变化。除了存储的数据量和速度明显增大之外，数据库在应用程序中的使用方式以及它们所部署的硬件类型也将发生重大变化。很难预测该领域的主要范式转变是什么，预测哪些数据库公司和产品仍然可用也是不现实的。因此，我发表一下对几个广泛主题的看法。

关系模型仍将主导大多数应用程序，但开发人员将不再需要过于担心其应用程序使用的数据模型。编程框架和DBMS之间的耦合将更加紧密，这样所有的数据库交互都将是透明的(并且是最佳的)。同样，SQL(或它的某种方言)将仍然是与DBMS交互的实际语言，但人类真实上永远不会编写SQL。相反，他们会用自然语言询问有关数据的问题。这些变化将导致我们编写程序的方式发生重大转变;开发人员以一种最容易被人类理解的方式对其数据进行建模，然后框架(与DBMS一起)将自动为其生成最佳存储方案。所有程序都将使用强一致的ACID事务执行。也就是说，在当今基于Web的应用程序中使用的最终一致性方法将避免增加管理的复杂性。在网络通信、并发控制和资源管理方面将会有重大的改进，这将使用ACID事务变得更好并具有可伸缩性。

将来会有越来越多的应用程序更自然地将数据存储在数组或矩阵中。这是因为组织需要分析大量的非结构化信息，尤其是视频。我们将掌握将所有非结构化数据转换成半结构化格式的能力，这种格式在DBMS中更容易组织和索引。作为其中的一部分，时效性也将变得重要，因为它关系到信息如何随时间的变化。目前的系统无法解释这一点，因为在一个时间序列中存储提取的每个视频帧的信息的开销很大。

无处不在的“物联网”将意味着每台设备都能够收集有关其环境的数据。这将包括从小型嵌入式传感器到大型自主机器人。小型设备将使用片上DBMS，就像手机现在包含片上视频解码器一样。所有这些系统的数据库将完全可以通过一些标准API(可能是SQL)进行组合和简易的联合。这意味着DBMS将以零配置彼此通信。你只需将两个DBMS相互指向对方，它们就会立即传递它们的信息，并确保它们是同步的。某些管理器服务将能够根据需要跨设备分发查询执行。人们将不需要手动配置提取-转换-加载实用程序或其他工具来保持不同系统上的数据一致。以这种方式使所有不同的DBMS可组合和可互操作将是一项重要的工程工作。因此，将会有一个使用人工智能或机器学习的工具包来自动地将不同的DBMS变体映射到彼此以进行相同的操作。

对于新的硬件，更灵活和可编程的制程将更普遍。DBMS将把程序的关键部分(例如锁管理器)编译到一个硬件加速器中。我们还将看到易失性和非易失性内存之间的二分法的消失。DBMS将假定所有内存都是快速和持久的，不需要维护变化无常的缓存。这种新存储器将比今天可用的存储器大几个数量级。因此，DBMS将在预先计算的物化视图中存储其数据的多个副本，以便快速响应任何可能的查询。

数据库管理员的角色将不复存在。这些未来的系统太复杂了，人类无法推理。DBMS最终将完全自治和自修复。同样，编程框架和DBMS之间的紧密耦合将支持系统在组织数据、提供资源和优化执行方面做出比人工生成计划更好的决策。

我们将看到星际设备(如太空探测器)数据库事务的增长。在这种情况下，在这些容器上运行的DBMS彼此之间的距离将比在地球上运行的系统要远得多，并且会导致明显较长的延迟(即延迟时间，分钟或小时)。这意味着在今天基于web的应用程序中使用的弱一致性技术和实践将被应用到这些星际系统中。

最后的最后，50年后我也已离开人世了吧。

原文：https://dev.to/seattledataguy/the-interview-study-guide-for-software-engineers-764

本文为 CSDN 翻译，转载请注明来源出处。

【End】