当SQL不管用时，“noSQL运动”兴起了……

Posted 2021-05-01 读芯术

全文共3360字，预计学习时长7分钟

图片来源：unsplash.com/@tjevans

毫无疑问，关系型数据库在企业事务中享有行业垄断地位。当正确搭建并抽象化地恰到好处，以解决实际问题为目的而不是仅仅追求架构的完成度时，关系型数据库用起来还是很顺手的。然而在很多情况下，关系型数据库往往面临着尴尬的问题。

关系型数据库之式微

上世纪八十年代，关系型数据库作为一种结构化数据的方式广受欢迎，还具有持久性和并发性等优点。结构化查询语言（Structured Query Language，缩写为SQL）是调用这些数据库的方式。如果想将软件和关系型数据库进行整合，或生成有意义的报告，则需要使用SQL.

然而，随着SQL证明了自己的实力，SQL支持的关系型数据库却在成长的压力以及与业务相关的战略枢纽的压力下走向崩溃（或者说已经崩溃）。对开发人员来说，抽象的纯度成了大问题，因为数据库的结构化方式与实际业务所需的格式数据之间存在“阻抗不匹配”。

当一个对象与数据库中的多个表格连接时，其呈现出的状态如上图——这可能导致需要调用FK关系，以获得所需的数据。

为了检索有意义的数据，要组装很多东西；但想存储某些内容时，要按相反顺序全部重做一遍。软件构建和关系型数据库针对特定问题会采取两种截然不同的方法。因此，当我们必须匹配它们时就麻烦了——要动用对象关系映射框架和各种翻译库。

#noSQL

关系型数据库在上世纪90年代将“对象数据库”的概念变为现实，这让一些人大失所望。对象数据库的目的之一是将面向对象的数据按原样保存在内存中，然后将它们录入数据库，而不必在保存的数据和要使用的数据之间创建映射。

但是对象数据库没有生根。或者更确切地说，他们不被允许生根，因为企业陷入了关系型SQL数据库的软件集成的困境。思维方式和工作方法之间存在着普遍的关系优势，软件集成是妨碍对象数据库普及的主要决定因素。

尽管如此，当互联网要求数据库能够以具有成本效益的方式扩展时，对象数据库开始成为数据存储空间中的竞争者。扩大单个窗口是昂贵的，而且到底能扩大多少也有限制。然而，通过扩张来扩大窗口，在增大和缩小规模的能力方面更具成本效益和弹性。但是，SQL数据库只能在单个窗口上运行，而不能在多个窗口的集群上运行。

改变游戏规则的挑战者

终于，谷歌和亚马逊忍不住采取行动了。谷歌在2005年推出了Bigtable，亚马逊于2012年向公众发布了DynamoDB .MongoDB在2009年成为开源软件，而使用javascript编写的查询更增添了它对开发人员的吸引力。其他无表格数据库也开始走入主流视野，如CouchDB，Cassandra，Dynomite和Apache Hbase。 

虽然SQL创建了一种较为标准化的调用关系数据库的方式，但上面列出的数据库有自己的要求和调用方法。然而，它们确实有许多共同点，比如它们都是非关系型、开源、集群友好和无模式的。 

正是这些激发了一场“noSQL运动”。一个有趣的事实是：noSQL原本是一个名叫Johan Oskarsson的人在旧金山组织非正式聚会时使用的twitter标签。 

由于其基础架构可扩展性，许多新企业和初创公司会考虑使用noSQL数据库。除此之外，依靠符合业务需求的数据模型（而不是依靠基于SQL的关系数据库或其他类似的东西），noSQL数据库可实现快速的软件开发和集成。  

noSQL的四种数据模型

数据模型抽象地描述数据特征。在关系模型里，数据通常构建在二维表中，并通过使用键值和相关约束来建立关系。对于noSQL数据来说，主要有四种思考数据的方法；其中有些方法甚至会根据需要混合和匹配这些思维模型。 

1. 键值

最简单的数据模型是键值存储。键值存储的基本思想是：数据库中有一个可以索引数据的键值，其附带的数据可以是任何东西。在某种程度上，它就像一个持久的散列映射，可以分布在不同的存储设备上。某些数据库允许存储有关键内值的元数据，以便创建复杂的索引。   

上图为键值模型。 与FK可以创建关系网的关系型数据库不同，键值模型不与其他任何东西相关联。 而且值是多少也无从知晓，这一点与可供部分查看、部分查询的文档不同。

2. 文档

文档可能是最流行的数据模型，它也通常被认为是noSQL的代表。文档可以以任何方式构造，并且可以根据需要变得复杂或简单。它被认为是无模式的，通常以JSON的形式出现。程序员可以在其中放入任何内容，且不会被数据库“吐出来”。毕竟很多人都有过这种苦恼：想用SQL添加一些东西，结果数据库一点也不配合。

文档通常以JSON的形式出现

调用noSQL数据库时，可以调用要返回的文档，或者查询文档结构。这使得程序员可以根据需要检索文档的某些部分。键值结构只返回数据，然而文档模型在数据透明性方面更具灵活性。 

3. 列族

列族有时看起来和关系表很相似。但是，它们在结构上并不相同。在关系型数据库中，这些会被分到另外一个有其他可能不相关的数据的表里。

列族仅记录相关数据。 它看起来有点像关系表，但它俩并不一样； 因为所见即所得： 程序员可以把任何想要的东西放进去。

在列族对象中，仅存在相关数据，并且它们被结构化为键值对。实际上总共有三列，其中一列是列名，第二列是值，第三列是时间戳。列族模型可以看作是不受模式限制的数据集合。

4. 图形

与其他三种noSQL模型相比，图形数据库提供了一种完全不同的数据思维方式。图形数据库非常善于通过节点和处理关系。

映射图形模型以存储关系

虽然顾名思义，“关系型数据库”擅长维护数据中的关系，但必须使用外键和复杂的连接来提取一组相关数据。连接太多通常会导致计算机冻结。

图形数据库是专门用来解决这个问题的，它有自己的查询语言作为响应。图形数据库本身就是自己的主题。

当noSQL也不管用时

noSQL非常适合解决可扩展基础架构问题，以及数据模型和软件兼容性之间的冲突。然而，它不能包治百病。SQL还是十分重要的。

虽然noSQL的最大卖点之一是它没有模式，但其实数据中仍然存在隐性模式。 

SQL数据库在其条目中显示关系和预期数据，并创建一定程度的一致性。至于noSQL数据库，则要由开发人员确保数据的正确性和一致性。没有辅助检查点来确保数据的完整性。代码最终会与此隐性模式绑定，并且需要进行自我监控以确保输入的所有内容都正确无误。

noSQL也没有强制并发一致性。这意味着，任何时候，在一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三者中，它只能实现两个。取对应英文的首字母，可以将这一现象称为“CAP定理”。

无论结构如何，只要noSQL数据库有分布式网络，就将获得网络分区——即不同节点之间的网络连接和沟通。如果无法连接到数据库本身，则无需选择其他两个选项。这使得一致性和可用性中只有一个能实现。SQL数据库就不会出现这个问题。

另一个主要问题是如何为数据集创建查询。值得一提的是，noSQL数据库通常能满足开发人员的需求，但它很难有效地满足分析师的需求。没有类似SQL的明确语言来与数据库连接，而且语言会因为所选平台不同而有所差异。仅根据数据本身的结构将数据通过文档集合在一起也是很低效的做法。

结语

世界上不存在一种能够完美应对所有数据的数据库或模型——也不应该存在。创建noSQL是为了解决开发人员使用关系型数据库时遇到的问题。大数据是一个相当现代的议题，在19世纪20世纪之交才出现。关系型数据库最初是在上世纪70年代早期提出的——“如何高效存储数据”这一问题背后的理念已经存在50多年之久了。

相比之下，noSQL更年轻；在新的解决方案出现之前，它还有很多需要学习、改进的地方。但不可否认的是，noSQL使软件开发变得更加容易，或者说它能更好地满足数据需求。可用的云服务（如Firebase，BigTable，DynamoDB和托管MongoDB）使开发人员可以更轻松地创建数据接口。

选择哪种数据库，最终还是要看个人需求。如果想要易于连接和开发迅速的，那么选用noSQL数据库可能是个好主意。如果想要熟悉的、开发人员操作熟练的，那么选用SQL可以实现稳定性和战略目的。

无论最终使用哪种数据库，请记住SQL和noSQL之间不是非此即彼的关系，不一定非要只选用其中一个。

我们一起分享AI学习与发展的干货

编译组：章文斐、何嘉琦

相关链接：

https://medium.com/better-programming/when-sql-isnt-the-right-answer-7d06902bc940

如需转载，请后台留言，遵守转载规范

推荐文章阅读

读芯君爱你