作者：Kyle J. Davis是Redis Labs的技术营销经理。
我在1999年开始上大学，那一年我学习SQL。我还记得设想在一台服务器上开发一个小小的应用程序，一行SQL触发了一连串惊人的操作。这种查询语言向磁盘控制器发出了命令，磁盘控制器继而在磁盘上移动驱动臂。磁头能够获取之前写入到磁性介质的数据。数据沿着线路高速发回到控制器，并通过操作系统发回到我的软件。这一切出现在短短几秒钟内。
那是大概20年前的事了。现在的学生会有全然不同的体验，一切都不一样。旋转介质的微机械方面被固态硬盘（SSD）取代。SSD是固态的，它们没有电机或驱动臂，完全是悄然无声的闪存。不过深入挖掘一番，它们仍模仿旋转磁盘的机械部件。数据库和文件系统仍然是为旋转磁盘世界设计的――大多数数据库软件专门设计成在移动介质世界的机械局限性范围内提供持久性。
现在，快进到20年后的2039年。我确信我们今天所做的事情将来看起来像拨号连接一样愚蠢。我不是未来学家，而是数据库人士。我考虑的是数据、如何存储和检索数据。
由于如今持久性内存技术成为现实，应用程序摆脱了物理介质所带来的束缚。随着我们对于数据库执行的操作的认识发生转变，情况开始变得模糊起来。持久性内存运行起来更像RAM，而不是像其他任何东西。此外，文件概念变得不那么重要了，因为文件系统（旋转磁盘时代的另一个遗迹）并不总是掉电的持久性数据所必不可少的。
有鉴于此，由于没有旋转介质的负担，数据库有点不一样。以下是内存计算未来的几个基本要素：
- 集群――持久性内存会比SSD更昂贵（至少最初是这样）。因此，对于即使中等大小的数据而言，仍然需要有一个跨多台机器的数据集。这需要出现在可以安全地提供数据持久性的最少数量的机器上。
- 协议和网络的优化――如果你消除了一个系统的所有类别的瓶颈，网络之类的部分就变得非常显然。开销很低的协议以及客户端与服务器之间可以异步访问的持久性连接，可确保内存数据存储的优势没有丢失。
- 高可用性――虽然即便基于磁盘的系统也常常需要高可用性，内存系统的更高吞吐量意味着哪怕短暂的中断也可能意味着数十亿个请求未得到处理。
此外，2039年编写的软件的架构将大不相同。现在，以不同方式提供数据的服务之间有着非常严格的界限。你可能有一个数据库来处理关系查询。今天，我们可以构建并不总是需要关系数据的应用程序，而是依赖已确立的NoSQL概念。不过，这仅在需要更高性能的情况下才执行，常常默认使用某个关系数据库来提供持久性和丰富的数据访问。如果你可以提供持久性内存以及对不同模型中的单个数据执行操作的方式，那么针对传统关系数据库的需求将仅限于一些非常具体的用途。
数据存储基本面随硬件而变化
在过去的几年，关系模型极其成功。你可以推理分析许多问题，并将它们放入到可以被操作和查询的规范化表中。这一招很管用，但如果你有一个较简单的问题要解决，比如说，通过主键获取某一项，就得解决大部分同样的复杂环节：查询、表和模式等。NoSQL（更具体地说键/值存储系统）使得这种方法看起来很可笑。
的确，考虑其他数据模型时，可以看到类似的模式。如果是时间序列数据，很简单，只需要轻量级摄取和最小模式，但关系数据库中的时间序列数据有负荷。图形数据尤其不适合实现到关系模型的上面，会从功能上破坏任何类型的内表互操作性，无法实现图形节点之间的临时关系。
正是由于这个棘手的问题，NoSQL界众多特殊用途的数据库应运而生。各自以自己的方式提供很出色的访问。然而这带来了自身的问题。每种数据库都必须由某人管理，扩展、监控和保护方面各自有着不同的特点。此外，这些数据库无法以有意义的方式相互联系，因而给依赖这些系统的应用程序带来了负担。
随着我们进入到未来，存储数据这个基本概念将从铁磁材料颗粒翻转极性变成可直接寻址的异常小的硅片层，可以快速操作和读取。由于硬件在变化，我们使用硬件的方式也应该随之变化。
由于数据库接近DRAM的CPU可寻址性，不过数据在掉电情况下保留下来，20年后我们的应用程序很显然会将数据视作又近又快，更类似程序内部的变量而不是远程数据库内部的变量。
数据作为一种最方便和最高效的模型而进入，然后数据库本身就能意识到该数据，以原子方式操纵该数据，并对该数据执行操作。数据改变了模型，可以替换原始样式或与之共存。应用程序可以根据需要立即检索新数据，而不是非得对单个关系模型执行巧妙的处理。再也不必担心如何扩展专用数据库，而是在最基本的层面操纵数据。不过，你仍然要解决传统的问题：集群、协议优化和高可用性，但处理局部性和数据库层内数据的可塑性消除了一大类问题。
2039年，我不知道我们是否会使用喷气式背包。然而，我很确信我们不会以1999年所熟悉的方式来使用数据库或编写应用程序。
