为什么 NoSQL 部署难以应对大规模扩展

作者 | Sunny Bains

译者 | 王强

策划 | 丁晓昀

NoSQL 的大规模扩展之路举步维艰，而分布式 SQL 则提供了更强大的解决方案。

一项技术为什么会过时？这个问题的答案并不是唯一的。有时，它是被某种更优秀的技术所超越。有时，潜在的需求在不断演变。当市场成熟时，之前满足了新兴市场需求的技术可能会变得不再够用。

许多企业对 NoSQL 的看法就是这样。这也是为什么今天如此多的 NoSQL 实现在艰难度日。

不久前，在大数据浪潮的早期，Hadoop 是人人都在谈论的话题。那时，传统上基于 SQL 的数据存储被认为已经过时。每家风险投资支持的初创公司似乎都有一个 NoSQL 键值存储。他们追随谷歌、Facebook 和雅虎等科技巨头的脚步，这些巨头开发了 NoSQL 技术来支撑他们的快速增长步伐。初创公司自然而然地会使用为其前辈的全球成果提供支持的工具。

但奇怪的事情发生了。很多成功的初创公司开始抛弃他们的 NoSQL 数据库。

考虑一下 Hbase 的发展轨迹，Hbase 这个数据库是作为标准 Apache Hadoop 软件包的一部分分发的。HBase 以谷歌著名的 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 解决方案缺乏一种模式（schema）。这既是它们的优势，也是劣势。缺少数据模式的设计可以实现快速存储和检索，但也让分析和事务跑起来更难了。如果模式未在数据库中实现，则必须在查询中实例化。例如，如果需要将数据分片到不同的服务器上，则更改必须反映在应用程序代码中。一些 NoSQL 解决方案允许在外部定义模式，但这种方法在实践中容易出错。模式迁移是脆弱且令人毛骨悚然的操作。

更改数据库的难度阻碍了新应用程序的开发。它使创新变得更加困难，很少有企业能长期容忍这种情况。

Pinterest 就是一个很好的例子。它是 HBase 的早期采用者。根据 Pinterest 的工程博客文章，它一度在 HBase 上运行着“50 个集群、9000 个 AWS EC2 实例和超过 6PB 的数据”。HBase 完成了这项任务。但随着时间的推移，随着 Pinterest 的发展，它认为 HBase 的缺点超过了它的好处——它的功能太少，管理成本太高。随着其他企业开始得出相同的结论，找到精通 HBase 的工程师变得越来越难。最终，Pinterest 迁移到了开源的、与 MySQL 兼容的分布式 SQL 解决方案 TiDB。结果，该公司提高了开发速度，减少了查询延迟，同时使性能更加可预测。

这可能会让一些人感到惊讶。多年来，SQL 一直被误解，人们以为它本质上比 NoSQL 更慢、效率更低，但事实并非如此。云计算和水平扩展的进步使最近的 SQL 解决方案的原始性能更接近 NoSQL 竞品，同时仍提供 RDBMS 的所有优势。分布式 SQL 并没有把注意力局限在数据库功能的一个维度——存储和检索上，而是寻求在广泛的事务和分析用例中提供出色的性能，这使得它对具有复杂需求和各种利益相关者的成熟企业具有很大吸引力。

讽刺的是，在从 NoSQL 转向分布式 SQL 的过程中，Pinterest 和类似的公司正在追随谷歌的脚步，就像他们最初采用 NoSQL 时一样。TiDB 和其他分布式 SQL 解决方案是 Google Spanner 的后继者。这是谷歌为解决 BigTable 问题而创建的软件，而 BigTable 恰恰是催生 HBase 的技术。

在某种程度上，SaaS 行业只是重演了谷歌和其他科技巨头过去二十年走过的历程。我们原来有一项技术（SQL/RDBMS），然后被另一项技术（NoSQL）淘汰了，而现在后者正在被它所取代的技术的更现代版本所取代。

谁能说轮子不会再次转动？最后引用 Stonebreaker 的话，“因果报应。另一波开发人员会声称 SQL 和 [关系模型] 不足以满足新兴应用领域的需求。然后人们会提出新的查询语言和数据模型来克服这些问题。”但他指出，没有一种数据库能够真正取代基于 SQL 的关系数据库管理系统。

这句提醒很有用，多年来，传统关系数据库已经证明其能够不断吸收创新。从集群到云再到矢量搜索，数据库架构的趋势来来去去，但不知何故，当尘埃落定时，SQL 似乎总是屹立不倒。

https://thenewstack.io/why-nosql-deployments-are-failing-at-scale/

声明：本文由 InfoQ 翻译，未经许可禁止转载。