SQL必须消失的九个理由，你认可吗？

译者 | 晶颜

审校 | 重楼

考虑到SQL的流行和成功，本文更像是一个悖论研究。SQL可能笨拙而冗长，但开发人员经常发现它是提取所需数据的最简单、最直接的方法。当查询写入正确时，它可以像闪电一样快，而当查询出错时，它又会慢得惊人。它已经存在了几十年，但新功能一直在不断增加。

这些矛盾并不重要，因为市场已经表明：SQL是许多人的首选，即使有更新的、更强大的选项。从最小的网站到最大的大型公司，各地的开发人员都知道SQL。他们依靠它来组织所有的数据。

SQL的表格模型如此流行，以至于许多非SQL项目最终都添加了SQLish接口，因为用户需要它。甚至是“NoSQL”运动——其发明是为了摆脱旧的范式——最终似乎也败给了SQL。

SQL的局限性可能不足以将其彻底抛弃。开发人员也可能永远不会着手将所有数据从SQL中迁移出去。但是SQL的问题是真实存在的，足以给开发人员带来压力，增加延迟，甚至需要对某些项目进行重新设计。

下面是我们希望放弃SQL的9个原因，尽管我们知道这可能做不到。

表格不能扩展

关系模型钟情于表格，所以我们一直在构建它。这对于小型甚至正常大小的数据库来说还好，但面对真正的大规模数据库，这个模型就会崩溃。

有些人试图通过将新旧结合起来来解决问题，比如将分片集成到旧的开源数据库中。添加层似乎可以使数据更易于管理，并提供无限的规模。但这些增加的层可能隐藏危险。根据分片中存储的数据量，SELECT或JOIN的处理时间可能会有很大的不同。

分片还迫使数据库管理员（DBA）考虑数据可能存储在不同的机器上，甚至可能存储在不同的地理位置上的可能性。没有经验的管理员在开始跨表搜索时，如果没有意识到数据存储在不同的位置，可能会感到困惑。该模型有时会将位置从视图中抽象出来。

一些AWS机器配备了24TB的RAM，因为一些数据库用户需要这么多。他们在SQL数据库中有这么多数据，而且这样能够运行得更好。

SQL不是JSON或XML原生的

SQL可能是一种“常青树式”的语言，但它并不特别适合JSON、YAML和XML等较新的数据交换格式。所有这些都支持比SQL更分层、更灵活的格式。SQL数据库的核心仍然停留在关系模型中，充斥着各种表格。

市场会想方设法掩盖这种常见的抱怨。使用正确的粘合代码添加不同的数据格式（如JSON）相对容易，但您将付出损失时间的代价。

一些SQL数据库现在能够编码和解码更现代的数据格式（如JSON、XML、GraphQL或YAML）作为原生特性。但是在内部，数据通常使用相同的旧表格模型进行存储和索引。

在这些格式之间转换数据要花费多少时间？用一种更现代的方式存储数据不是更容易吗？一些聪明的数据库开发人员仍在继续进行实验，但奇怪的是，他们经常会使用某种SQL解析器。

封送（Marshaling）是一项耗费大量时间的工作

数据库可以在表中存储数据，但是需要程序员编写处理对象的代码。设计数据驱动的应用程序的大部分工作，似乎都是找出从数据库中提取的数据并将其转换为业务逻辑可以处理的对象的最佳方法。然后，必须通过将对象中的数据字段转换为SQL upsert来解组数据。难道没有一种方法可以让数据保持一种随时可用的格式吗？

SQL并非实时的

最初的SQL数据库是为批处理分析和交互模式而设计的。具有长处理管道的流数据模型是一个相对较新的想法，而且它并不完全匹配。

主要的SQL数据库是在几十年前设计的，当时的模型设想数据库可以独立运行，像某种Oracle一样回答查询。有时它们反应迅速，有时则不然。这就是批处理的工作方式。

一些最新的应用程序要求更好的实时性能——不仅仅是为了方便，而且因为应用程序需要它。在现代的流媒体世界里，缺乏实时功能是行不通的。

为这些市场设计的最新数据库非常重视速度和响应能力。它们不提供那种复杂的SQL查询，以免造成延迟。

JOIN是一个令人头疼的问题

关系数据库的强大之处在于将数据分解成更小、更简洁的表。不过，问题也随之而来。

使用JOIN动态地重新组装数据通常是作业中计算成本最高的部分，因为数据库必须处理所有数据。当数据开始超出RAM时，问题就开始了。

对于学习SQL的人来说，JOIN可能会让人十分困惑。弄清楚内部JOIN和外部JOIN之间的区别仅仅是个开始。寻找将多个JOIN连接在一起的最佳方式更为困难。内部优化器可能会帮上忙，但是当数据库管理员要求一个特别复杂的组合时，它们就无能为力了。

列（Column）是对空间的浪费

“NoSQL”运动的一个伟大思想就是让用户从列中解脱出来。如果有人想向条目添加新值，他们可以选择他们想要的任何标记或名称。不需要更新模式来添加新列。

SQL捍卫者在该模型中只看到了混乱。他们喜欢表自带的顺序，不希望开发人员匆忙添加新字段。他们有一定的道理，但是添加新列可能非常昂贵和耗时，特别是在大型表中。将新数据放在单独的列中并使用JOIN对它们进行匹配会增加更多的时间成本和复杂性。

优化器并非始终有用

数据库公司和研究人员已经花费了大量时间开发优秀的优化器，这些优化器可以分解查询并找到排序其操作的最佳方式。

收益可能是显著的，但是优化器所能做的是有限的。如果查询需要一个特别大的或细致的响应，那么优化器不能只是说，“你真的确定吗？”它必须把答案集合起来，然后按照指令去做。

有些数据库管理员只有在应用程序开始扩展时才意识到这一点。早期的优化足以在开发期间处理测试数据集。但是在关键时刻，优化器无法发挥更多的功能。

反范式化（Denormalization）将表视为垃圾

面对想要更快性能的用户和不想为更大、更昂贵的硬件付费的用户，开发人员经常处于两难境地。一种常见的解决方案是对表进行反范式化处理，这样就不需要复杂的JOIN或跨表操作。

这并非一个糟糕的技术解决方案，而且它经常获胜，因为磁盘空间已经变得比处理能力便宜。但是反范式化也抛弃了SQL和关系数据库理论中最精华的部分。当数据库变成一个长CSV文件时，所有这些花哨的数据库功能几乎都消失了。

附加特性会破坏数据库

多年来，开发人员一直在为SQL添加新特性，其中一些非常优秀。但另一方面，有些新特性可能会导致性能问题。一些开发人员警告称，“您应该特别小心子查询（Subqueries），因为它们会减慢所有操作的速度”。另一些人则表示，“选择像公共表表达式、视图或windows这样的子集会使代码过于复杂”。

例如，窗口函数（Window function）的设计是为了通过加速计算结果（如平均值）来加快基本数据分析的速度。但是许多SQL用户会发现并使用一些附加的特性。在大多数情况下，他们会尝试新功能，只有当他们的机器慢得像爬行一样时才会注意到这些问题。然后他们会需要一些经验丰富的数据库管理员来解释发生了什么以及如何修复它。

原文标题：9 reasons SQL has got to go，作者：Peter Wayner