数据库的前世今生

【CSDN 编者按】被称之为基础软件三驾马车之一的数据库，在经历了条理型和网状型、关系型数据型库以及更加强大的数据管理功能等三个时期之后，其在将来的发展历程中另有哪些更多的可能性？
基于此，卡内基梅隆大学盘算机科学系数据库学副传授 Andy Pavlo 曾于 2015 年为 CMU 盘算机科学系 50 周年庆典上写下了自己对于数据库将来 50 年的构想。
在本文中，他提出了几点：关系模型对于大多数应用而言仍将占据主导职位，开辟框架和数据库管理体系将更加精密地耦合在一起，从而使所有数据库交互都透明化，SQL 仍然是与 DBMS 交互的实际语言，但人类永远都不会真正编写 SQL，将以自然语言查询相关数据问题，这将导致编程方式发生重大变化。无所不在的「物联网」意味着每个设备都能收集其情况的数据，对于新硬件，更灵活和可编程的处理结构将更为广泛，人类作为数据库管理员的角色将不复存在，DBMS 最终将完全自治和自我修复，星际设备的数据库事务将兴起，最终，「我将在 50 年后去世」。

                               
登录/注册后可看大图

作者 | Andy Pavlo
译者 | 谭开朗，责编 | 屠敏
出品 | CSDN（ID：CSDNnews）
以下为译文：
最终，我还是从事了我曾扬言不会从事的职业：成为一名传授，有自己的博客，但从不更新。我知道，距离我上次发表文章已有一年之久，我也必要给事务处理数据库体系这一开放议题撰写第三部分内容。去年在CMU发生了很多事情，我计划在项目更加完善后再在这里讨论。预告几点：

• 我们正在开辟一个新的分布式DBMS；
  
• 我们正在构建一个用于测试和基准化分析的“准备启用的”大型OLTP应用步调库；
  
• 我们正在创建一个在线数据库体系百科全书。
  

固然，另有很多并发控制和非易失性内存工作。毫无疑问，我的课外传授活动已经顾不太上了。
以下是我写的一篇文章，作为下个月CMU盘算机科学系50周年庆典的一部分。我们每个教员的任务是：针对自身所在的领域，展望其在2065年的发展概况。所以，我的任务是概述数据库体系在50年后的样子。但是，在我展望将来之前，我首先花一些时间来讨论数据库的过去和现在。

                               
登录/注册后可看大图

数据库的过去
第一个数据库管理体系(DBMS)在1968年上线。IBM的IMS用于跟踪土星5号和阿波罗太空探索项目标供应和零部件库存。它引入了这样一种头脑，即应用步调的代码应该与它所操作的数据分离。由此支持开辟人员编写只关注数据访问和操作的应用步调，而不关注与执行这些操作和确保数据安全相关的复杂性和开销。IMS之后，在20世纪70年代早期，IBM的System R和加州大学的INGRES率先开辟了第一个关系型DBMS。
第一批体系的数据库工作负载没有本日那么复杂和多样化。在这些早期的应用步调中，操作员通过终端启动事务，然后手动向体系输入新数据。此时，DBMS的预期峰值吞吐量仅为每秒数十到数百个事务，响应时间以秒为单元度量。这些早期DBMS的体系结构也基于当时流行的盘算硬件。它们通常部署在只有一个CPU焦点和少量主内存的盘算机上。对于这些体系来说，磁盘是数据库的主要存储位置，由于磁盘可以或许存储比内存更大的数据，而且本钱更低。

                               
登录/注册后可看大图

数据库的现在
尽管在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以满意这些应用步调的需求已经超出了人类的能力。

                               
登录/注册后可看大图

数据库的将来
在接下来的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】

转发了

转发了