作者：Avishai Ish-Shalom是ScyllaDB公司的开发者推广人员。这似乎是孩子会提的一个问题：“为什么是这个样子？”人们忍不住会回答“因为一直都是这个样子。”不过这么回答是错误的。我们遇到的每个工具、每个系统和每个实践都是在某个时间点设计出来的。它们是出于特定原因，以特定方式设计的。尽管当初的理由早已消失，这些设计常常如古董一般继续存在。它们继续存在，或历久弥新，或每况愈下。一个著名的例子是QWERTY键盘，它是发明家Christopher Latham Sholes在19世纪70年代设计的。常见的说法是，Latham设计QWERTY布局的初衷不是提高打字员的打字速度，而是放慢速度，因为早期打字机的拉杆容易卡住。从某种意义上说，这是一种优化而已。打字比较慢但从不卡住的打字员其工作效率高于打字比较快但常卡住的打字员。新一代打字机很快消除了困扰早期打字机的卡住问题。但是尽管无数人一心想改革，并付出了百般努力，原来的QWERTY布局这些年来仍然唱主角。这是网络效应起作用的一个典例。一旦足够多的人采用了QWERTY，他们的习惯就会更根深蒂固。打字员想要QWERTY，于是制造商制造更多的QWERTY键盘来满足需求。QWERTY键盘制造商制造的键盘越多，学习用QWERTY键盘打字的人就越多，网络效应也就越强。心理因素也发挥了作用。我们天生喜欢熟悉的东西。“明枪易躲，暗箭难防”和“如果它没坏，别修复它”，诸如此类的说法反映了一种名为“纯粹接触效应”（Mere Exposure effect）的原则。该原则是指，我们往往倾向于以前用过的东西，就因为我们用过。研究人员发现，这个原则推而广之到生活的方方面面：我们觉得诱人的形状、觉得愉悦的说话方式、觉得舒适的地方，以及喜欢在上面敲打的键盘。还有我们用于构建应用程序的软件设计。软件很灵活。软件应该与时俱进，但并不总是如此。我们仍在为几十年前存在的硬件设计基础架构；这种不和谐在一些地方开始显现出来。Hadoop就是个典例，它表明了这个过程是如何显现的。你可能还记得，Hadoop是一种开源分布式计算框架，基于谷歌在2000年代初发布的白皮书。那时候，RAM还比较贵，磁盘是主要的存储介质，网络带宽有限，文件和数据集很庞大，让计算靠近数据比让数据靠近计算更高效。除此之外，Hadoop要求服务器放在某个位置：某个特定的机架或数据中心。Hadoop的一项关键创新是使用大众化硬件，而不是专用的企业级服务器。今天仍然是这个原则。不过在Hadoop设计出来到部署于实际应用环境这段期间，其他“实际情形”已发生了变化。旋转磁盘让位于SSD闪存。RAM的价格下跌，RAM容量急剧增加。专用服务器换成了虚拟化实例。网络吞吐量增加。软件开始迁移到云端。为了对变化的速度大致有所了解，须知在2003年，一台典型的服务器会搭载2 GB的RAM和一块数据传输速度为每秒100 MB的50 GB硬盘，网络连接每秒可以传输1 Gb。到2013年Hadoop进入市场时，服务器会搭载32 GB的RAM、数据传输速度每秒达150 MB的2 TB硬盘驱动器以及每秒可以传输10 Gb的网络。Hadoop是为烟消云散的旧世界设计的，其架构在它进入市场时已经过时了。开发人员很快抛弃了它，改而使用Spark（2009年）、Impala（2013年）和Presto（2013年）。在这短短的时间内，Hadoop催生了数家上市公司，媒体报道非常密集。它对技术行业产生了短暂而又重大的影响，尽管等到它家喻户晓时，已经过时了。Hadoop在短短十年内走完了从构思、开发到废弃的全过程。因此，这似乎令人难以置信：软件在没有重大变化的情况下可以用上五十年，大型机和绿屏显示器时代构思的设计今天依然伴随我们。不过这正是我们在关系数据库上看到的一幕。这种持久性在关系数据库管理系统（简称RDBMS）上体现得尤为明显。按技术标准而言，RDBMS设计相当旧，历史比Hadoop久多了，起源于上世纪七八十年代。关系数据库比互联网早问世，它来自广泛联网、廉价存储、能够将工作负载分散在多台机器上、广泛使用虚拟机以及云计算之前的那个年代。不妨看看RDBMS的时代，流行的开源Postgres比最初于1995年面市的CD-ROM还要久远。Postgres是在大约1986年开始的项目上构建的。所以这种设计很旧。当时其背后的想法很有道理，但此后许多方面发生了变化，包括硬件、使用场景以及网络拓扑结构。同样，RDBMS的核心设计基于这种假设：吞吐量低，RAM昂贵，大容量磁盘价格贵且速度慢。考虑到这些因素，RDBM设计人员得出了某些结论。他们认为存储和计算应该与专用硬件和大量RAM集中放在一个地方。他们还意识到，与本地存储和处理结果相比，客户端与远程服务器进行通信会更高效。今天的RDBMS架构仍体现了底层硬件方面的这些老观念。问题在于，那些观念不再成立。RAM的便宜程度是上世纪60年代的人无法想象的。闪存SSD价格低廉，响应异常迅即，延迟在50微秒左右，而老式旋转磁盘约10毫秒。网络延迟变化倒是不大，仍在1毫秒左右，但带宽增加了100倍。结果是，即便在如今容器、微服务和云计算大行其道的时代，大多数RDBMS架构将云视为虚拟数据中心。这不仅仅是对过去的迷人提醒，它对数据库的成本和性能也有重要影响。两者都糟糕得多，因为它们受到50年前大型机时代所做的设计决策的制约。关系数据库比NoSQL数据库要慢的原因之一是，它们在确保数据安全方面投入了大量精力。比如说，关系数据库避免在磁盘层上进行缓存，采用ACID语义，立即写入到磁盘上，并保留其他请求直到当前请求完成为止。基本想法是，这些预防措施到位后，如果出现问题，管理员始终可以将磁盘拿去分析，恢复丢失的数据。但是现在这几乎没有必要，至少对于云端运行的数据库而言是这样。以AWS为例。其标准的Elastic Block Storage系统可自动进行备份并自由复制。传统的RDBMS架构假定它们在存在单一存储故障点的单台服务器上运行，因此不遗余力地确保数据正确存储起来。但是当你在云端运行多台服务器时，如果某一台服务器出了问题，只需故障切换到某一台正常运行的服务器即可。RDBMS竭尽全力支持数据持久性。但是由于现代环境偏爱即时故障切换，所有的努力付之东流。如今，你遇到故障后切换到一台复制的服务器，而不是为崩溃的服务器恢复正常等上一天。然而，RDBMS继续格外注重冗余性。即使不再需要冗余性，业务和技术需求也常常要求有这项功能——这个例子充分表明了实践和期望如何强化过时的设计模式。在云计算之前的时代，客户端/服务器模式很合理。如果你的网络比较快（过去如此），磁盘比较慢（过去也如此），最好在定制的专用服务器上运行热数据，该服务器接收来自远程客户端的查询。因此，关系数据库最初假定它们连接了可靠的物理磁盘。但是一旦这种情况有变，本地SSD可以迅速找到数据，比通过网络传输数据更快，应用程序本地读取数据更合理。但目前我们无法做到这一点，因为数据库不是这么运作的。这样一来就很难扩展RDBMS，哪怕使用比较小的数据集，而且处理大型数据集的性能比本地驱动器差得多。这反过来使解决方案变得更复杂更昂贵，比如说要求缓存层提供可以用快速本地存储更便宜更轻松地实现的速度。RAM过去非常昂贵。只有专门的服务器才有大量RAM，以便数据库在上面运行。许多经典的RDBMS设计都围绕在磁盘和RAM之间移动数据这一原则。但是云再次使这成为不值得争论的问题。AWS为你提供了大量的RAM，只需花少量的钱。但是大多数运行传统数据库的人实际上用不了这么多的RAM。配备8 GB RAM的应用程序服务器并不少见，而在上面运行的软件只能访问1 GB，这就意味着大约90%的RAM容量白白浪费了。这很要紧，因为你可以用RAM处理很多事。数据库不仅存储数据，还执行处理工作。如果客户端上有大量RAM，可以用来缓存数据，或者可以用来保存副本，因而可以完成服务器端通常执行的许多处理工作。但是你现在没有这么做，因为这违反了RDBMS的设计。图省事要花精力。但是软件开发人员常常选择不花精力。毕竟，正如Perl的发明者喜欢说的那样，懒惰是杰出程序员的美德之一。我们宁愿在现有知识的基础上构建，不愿从头开始发明新系统。但是采用传统设计原则要付出代价，即使它不是像RDBMS这样的基础技术。我们往往认为技术总是在进步。RDBMS提醒我们一些模式因人们的惰性而存在。它们变得再熟悉不过，以至于我们再也看不到。它们是我们眼皮子底下的古董。一旦你发现它们，问题在于如何处理。有些东西存在是有其原因的。成熟确实很重要。你需要像会计师那样，冷静客观地分析一下投资回报率。如果你的设计基于过时的观念，它是否在拖你的后腿？它花费的钱是否比更新改造所花费的还多？你能否真正获得积极的回报？这确实是大好机会。亚马逊通过重新思考RDBMS存储抽象背后的核心观念，设计出了一款全新的产品：Aurora数据库。
你可能没有那么幸运。但只要至少有希望获得积极的投资回报率，这就是很好的迹象：表明变化具有战略意义，这也表明拆掉自己的设计、设计取而代之的新系统是值得的。
参考资料：https://www.nextplatform.com/2021/03/25/the-world-has-changed-why-havent-database-designs/
