原创 Sunny Bains 2024-10-21 07:15 广东
多年来，人们一直误以为 SQL 比 NoSQL 速度慢、效率低，但事实并非如此。
之前一篇名为《50年了！为什么我们仍在使用SQL？》的文章，引发了大家的激烈讨论。在技术迭代迅猛的计算机行业，SQL 50年经久不衰，并被大家预判在可预见的未来甚至更远，会一直发挥作用。
最近，小编在The New Stack上看到《为什么 NoSQL 部署在大规模情况下会失败？》这一篇文章，从企业发展的角度，评析了SQL存在的重要意义，希望能给大家带来一些启示。
为什么技术会过时？这个问题没有统一的答案。有时是被某种更先进的技术超越，有时是潜在（新兴市场）的需求不断演变……
这就是许多企业对NoSQL 的认识，也是为什么如今许多 NoSQL 实施都举步维艰。
不久前，在大数据发展的早期，Hadoop 是人们热议的话题，传统的基于 SQL 的数据存储被认为已经过时。每家获得风险投资的初创公司似乎都拥有 NoSQL 键值存储，他们追随谷歌、Facebook 和雅虎等科技巨头的脚步（这些巨头开发了 NoSQL 技术来管理其快速增长），初创公司自然而然地会采用为其前辈在全球取得成功提供支持的工具。
但奇怪的是，成功的创业公司开始抛弃 NoSQL 数据库。
代入一下 Hbase 的发展轨迹。Hbase 是作为标准 Apache Hadoop 软件包的一部分而发布的数据库。HBase 以 Google 著名的 BigTable 为蓝本，其受欢迎程度在几年内飙升，然后逐渐下降。
从上面的图表来看，人们可能会认为 2017 年出现了一种新的数据库来取代 HBase —— 也许是一种可以更快地存储和访问数据，或可以处理更多信息的数据库。但事实并非如此，HBase 仍然存储和检索其中最好的数据，它的受欢迎程度下降与其原始功能无关，而是与其用户试图解决的问题的复杂性有关。
在 SaaS 和大数据发展的早期，初创公司忙于跟上客户的增长。他们需要一种廉价的方式来存储和管理大量高速数据，HBase 等 NoSQL 工具出色地完成了这一任务。但查询这些数据如何保持一致性？这些是后面才要思考的问题。
最终，这一刻到来了。很明显，当它到来时，基于 NoSQL 构建的公司存在巨大的维护问题。他们在编写查询时遇到困难，数据变得不可靠，新应用程序越来越难构建，NoSQL 最初非常具有成本效益，但随着业务变得越来越复杂，维护它开始则产生了成本。
此时，许多运行 HBase 的公司已不再是初创公司，它们已在全球扩张，创建了其他人用来建立业务的平台，并开始招聘数据分析师，同时考虑停机时间和 SLA，不再只是试图保存数据，而是开始使用数据。
正是在那时，NoSQL 的局限性开始显现出来了，并且成为一个真正的问题。
对于 HBase，包括：
缺乏事务支持：这意味着用户无法获得现代关系数据库典型的 ACID 属性，数据可能会损坏或逻辑不一致。数据越多，当数据质量下降时，通过蛮力找到问题就越困难。
缺少二级索引： HBase 缺少二级索引，这意味着必须通过强力扫描才能找到所有内容。当您不需要查找数据时，这不是问题；当您的数据量相对较少时，这不是问题；但是，当您需要在 TB 级大海捞针时，缺少二级索引会使每个查询的计算成本很高。
单点故障： HBase 使用 HDFS 文件系统（带有其集中式 NameNode 目录）创建了依赖关系，这使其极易崩溃。
界面不友好：NoSQL 缺乏关系架构，这对于快速存储数据来说是一个优势，但对于查询数据来说却是一个根本问题。NoSQL 并没有消除对关系模式的需求。它只是将负担强加给应用程序，而应用程序的维护难度和成本要高得多，使用数据结构更改显式 SQL 数据库模式，比修改应用程序中嵌入的隐式模式要容易得多。
随着时间的推移，大规模运行 NoSQL 的这些基本问题变得无法忽视。一些人试图找到一个折衷的解决方案，较新的 NoSQL 数据库试图在 HBase 的键值架构上分层结构，添加具有 SQL 或类似 SQL 功能的事务。
正如麻省理工学院的 Michael Stonebreaker 所说：“尽管有人强烈表示 SQL 很糟糕，但到 2010 年代末，几乎每个 NoSQL DBMS 都添加了 SQL 接口。”他补充道：“许多剩余的 NoSQL DBMS 还添加了强一致性 (ACID) 事务。因此，NoSQL 消息已从‘不要使用 SQL — 它太慢了！’转变为‘不仅仅是 SQL’（即SQL 对于某些事情来说很好）。”
随着时间的推移，NoSQL 产品开始变得与 RDBMS 产品相似，但本质区别仍然存在。根据定义，NoSQL 解决方案缺乏模式，这是它们的优势，也是劣势。缺乏数据模式可以实现快速存储和检索，这也使分析和交易更加困难。如果模式未在数据库中实现，则必须在查询中实例化。
例如，如果需要将数据分片到不同的服务器上，则更改必须反映在应用程序代码中。一些 NoSQL 解决方案允许在外部定义模式，但这种方法在实践中容易出错，模式迁移是脆弱且令人毛骨悚然的操作。
更改数据库的难度阻碍了新应用程序的开发，它使创新变得更加困难，很少有企业能长期容忍这种情况。
HBase 的早期采用者Pinterest，就是一个很好的例子。根据 Pinterest 工程博客文章，它一度在 HBase 上运行“50 个集群、9000 个 AWS EC2 实例和超过 6 PB 的数据”。早期HBase 完成了任务，但随着时间的推移和Pinterest 的发展，他们发现 HBase 的缺点超过了它的好处，它的功能太少，管理成本太高。
随着其他企业也开始得出同样的结论，找到精通 HBase 的工程师也变得越来越难。最终，Pinterest 迁移到了TiDB（与 MySQL 兼容的分布式 SQL 开源数据库）。迁移后，该公司提高了开发速度并降低了查询延迟，同时使性能更可预测。
这可能会让一些人感到意外。多年来，人们一直误以为 SQL 比 NoSQL 速度慢、效率低，但事实并非如此。云计算和水平扩展方面的进步，使最近的 SQL 解决方案更接近与 NoSQL 同类解决方案的原始性能对等，同时仍提供 RDBMS 的所有优势。分布式 SQL 并非专注于数据库功能的一个维度（存储和检索），而是寻求在广泛的事务和分析用例中提供高性能，这使其对具有复杂需求和各种利益相关者的成熟企业具有吸引力。
讽刺的是，在从 NoSQL 转向分布式 SQL 的过程中，Pinterest 和类似的公司正在追随谷歌的脚步，就像他们最初采用 NoSQL 时一样。TiDB 和其他分布式 SQL 解决方案是 Google Spanner 的后代。这是谷歌为解决 BigTable 问题而创建的软件，BigTable 是 HBase 的诞生技术。
某种程度上，SaaS 行业只是重演了谷歌和其他科技巨头过去 20 年走过的历程。现在，一项技术（SQL/RDBMS）本应被另一项技术（NoSQL）淘汰，而后者现在正被更现代的技术所取代。
谁能保证轮子不会再次转动？最后引用 Stonebreaker 的话：“因果报应。另一波开发人员会声称 SQL 和 [关系模型] 不足以满足新兴应用领域的需要，然后人们会提出新的查询语言和数据模型来克服这些问题。”但他指出，没有一种语言和模型能够真正取代基于 SQL 的关系数据库管理系统 (RDBMS)。
这是一个有用的提醒，多年来，传统的关系数据库已经证明其具有吸收创新的卓越能力，从集群到云到矢量搜索。数据库架构的趋势来来去去，但不知何故，当尘埃落定时，SQL 似乎总是屹立不倒。
作者丨Sunny Bains 编译丨Rio
来源丨https://thenewstack.io/why-nosql-deployments-are-failing-at-scale/
*本文为dbaplus社群编译整理，如需转载请取得授权并标明出处！欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
活动推荐
在AI的驱动下，数据库技术实现了更多元化的更迭与创新。这对于企业用户而言，在有了更多选择的同时，也面临着新旧产品和技术替换、迁移、兼容等架构设计和运维管理难题，第九届DAMS中国数据智能管理峰会将于2024年11月29日在上海举办，携手一众产学研界技术领跑单位，带来新思路、重实践、可落地的全日干货盛宴。早鸟优惠，码上报名↓
