在开发应用程序时，不可避免地要选择是使用SQL还是NoSQL数据库来存储数据。传统数据库，即使用SQL（结构化查询语言）查询的关系数据库，是数十年技术发展、良好实践和现实世界压力测试的产物。它们专为可靠的交易和临时查询而设计，是业务线应用程序的主力。但它们也有限制，例如严格模式，这使得它们不太适合其他类型的应用程序。NoSQL数据库就是出于这些限制而诞生的。NoSQL系统存储和管理数据的方式允许高速运行，并为开发人员提供了极大的灵活性。许多数据库是由谷歌、亚马逊、雅虎和Facebook等公司开发的，旨在寻求更好的方法来为大型网站存储内容或处理数据。与SQL数据库不同，许多NoSQL数据库可以横向扩展到成百上千台服务器。然而，NoSQL的优势并非没有代价。NoSQL系统更看重速度和可扩展性，而不是SQL数据库承诺的可靠事务背后的ACID属性。与围绕SQL建立的数十年机构知识相比，NoSQL系统中用于处理数据的隐喻也相对较新。SQL和NoSQL数据库提供不同的权衡。虽然他们可能会在特定项目的背景下竞争，例如作为不同应用的替代方案，它们在更大范围内是互补的，每个都适用于不同的用例。选择SQL还是NoSQL并不是绝对的，要根据场景的需要选择合适的。NoSQL和SQLSQL和NoSQL之间的根本区别并没有那么复杂。关于如何存储和检索数据，两者都有不同的理念。对于SQL数据库，所有数据都具有固有结构。MicrosoftSQLServer、MySQL、PostgreSQL或Oracle数据库等传统数据库使用架构——插入数据库的数据的组成方式的正式定义。例如，表中的列可能仅限于整数。因此，该列中记录的数据将具有高度规范化。SQL数据库的严格模式也使得聚合数据变得相对容易，例如，使用SQLJOIN命令合并两个表的数据。在NoSQL中，数据可以以无模式或自由的方式存储。任何数据都可以存储在任何记录中。在NoSQL数据库中，您会发现四种常见的数据存储模式，这导致了四种常见类型的NoSQL系统。文档数据库（例如MongoDB）。插入的数据存储为无模式的JSON结构或“文档”，其中数据可以是从整数到字符串再到自由格式文本的任何内容。无需指定JSON文档将包含哪些字段（如果有）。键值存储（例如Redis）。自由格式的值，从简单的整数或字符串到复杂的JSON文档，都可以通过字符串等键在数据库中访问。宽列存储（如Cassandra）。数据存储在列中，而不是传统SQL系统中的行。可以根据查询或数据视图的需要对任意数量的列（以及许多不同类型的数据）进行分组或聚合。图形数据库（例如Neo4j）。数据表示为实体及其关系的网络或图形，其中图形中的每个节点都是一个自由格式的数据块。无模式数据存储在以下情况下很有用。您想要快速访问数据，并且比可靠的事务或一致性更关心访问的速度和简单性。您正在存储大量数据，并且不想将自己锁定在模式中，因为以后更改模式可能既缓慢又痛苦。您正在从一个或多个来源接收非结构化数据，并且希望将数据保留为原始格式以获得最大的灵活性。您希望将数据存储在层次结构中，但您希望这些层次结构由数据本身而不是外部模式来描述。NoSQL允许数据随意自引用，这对于SQL数据库来说更加复杂和难以模仿。查询NoSQL数据库关系数据库使用的结构化查询语言提供了一种在存储和检索数据时与服务器通信的统一方式。SQL语法是高度标准化的，因此虽然各个数据库可能以不同方式处理某些操作（例如，窗口函数），但基本原理是相同的。相比之下，每个NoSQL数据库往往都有自己的查询和管理数据的语法。例如，CouchDB使用通过HTTP发送的JSON形式的请求来创建或检索其数据库中的文档。MongoDB通过二进制协议发送JSON对象，作为命令行界面或语言库。一些NoSQL产品可以使用类似SQL的语法来处理数据，但仅限于一定程度。例如，ApacheCassandra是一个广泛的列存储，它有自己的类似SQL的语言，即Cassandra查询语言(CQL)。CQL的一些语法直接来自SQL手册，例如SELECT或INSERT关键字。但是在Cassandra中没有原生的方式来执行JOIN或者子查询，所以CQL中不存在相关的关键字。NoSQL系统的一个常见设计选择是“无共享”架构。在无共享设计中，集群中的每个服务器节点都独立于其他节点运行。系统不需要征得其他节点的共识就可以向客户端返回数据。查询很快，因为它们可以从最近或最方便的节点返回。无共享系统的另一个优势是弹性和横向扩展。扩展集群就像在集群中启动新节点并等待它们与其他节点同步一样简单。如果一个NoSQL节点出现故障，集群中的其他服务器将继续运行。即使服务请求的节点更少，所有数据仍然可用。请注意，无共享设计并不是NoSQL数据库独有的。许多传统的SQL系统可以以无共享的方式设置，例如MySQL，尽管这通常会为了性能而牺牲整个集群的一致性。NoSQL的局限性如果NoSQL提供了如此多的自由和灵活性，为什么不完全放弃SQL？答案很简单，许多应用程序仍然需要SQL数据库提供的约束、一致性和保证。在这些情况下，NoSQL的一些“优势”可能会变成劣势。其他限制来自于NoSQL系统缺少SQL世界中应该存在的某些特性。(1)无模式（Noschema）即使你接收的是自由格式的数据，你几乎总是需要对数据施加约束以使其有用。使用NoSQL，施加约束涉及将责任从数据库转移到应用程序开发人员。例如，开发人员可以通过对象关系映射系统（或ORM）强加结构。但是如果你希望模式与数据本身共存，NoSQL通常不支持。一些NoSQL解决方案提供了可选的数据类型和数据验证机制。例如，ApacheCassandra有一系列原生数据类型，让人联想到传统SQL中的数据类型。(2)最终一致性NoSQL系统提供了强一致性或即时一致性的选择，以获得更好的可用性和性能。传统数据库确保操作是原子的（事务的所有部分或都不成功）、一致的（所有用户对数据有相同的视图）、隔离的（事务不竞争）和持久的（一旦完成，他们将不会受服务器故障影响）。这四个属性统称为ACID，可以在NoSQL系统中以不同的方式处理。您可以选择最终一致性，而不是要求整个集群的强一致性，这必然会延迟对请求的响应，从而允许请求得到服务而无需等待最新的写入被复制到集群的其余部分。插入集群的数据最终随处可用，但不保证始终可用。对于一些NoSQL系统，可以在一致性和速度之间做出折衷，不同的产品有不同的解决方案。例如，Microsoft的AzureCosmosDB允许您选择每个请求的一致性级别，因此您可以选择适合您的级别。事务语义，在SQL系统中保证事务中的所有步骤（例如执行销售和减少库存）都完成或回滚，并且在一些NoSQL系统中也可用，例如MongoDB。(3)NoSQL中的锁定大多数NoSQL系统在概念上相似但实现方式不同。每个系统都有自己的隐喻和机制来查询和管理数据。这样做的副作用是应用程序逻辑和数据库之间可能存在高度耦合。如果您选择一个NoSQL系统并坚持使用，这种耦合不会造成伤害，但如果您将来更改系统，它就会成为绊脚石。如果您要从MongoDB迁移到CouchDB（或相反），您需要做的不仅仅是迁移数据。还必须了解数据访问和编程隐喻之间的区别。换句话说，您必须重写应用程序中访问数据库的部分。(4)NoSQL技能NoSQL的另一个缺点是相对缺乏专业知识。传统SQL人才市场规模庞大，而NoSQL技能市场才刚刚起步。作为参考，Indeed.com报告称，到2022年，传统SQL数据库（MySQL、MicrosoftSQLServer、Oracle数据库等）的工作数量仍将超过MongoDB、Couchbase和Cassandra。对NoSQL专业知识的需求仍然存在仅占SQL技能市场的一小部分。合并SQL和NoSQL在未来，SQL和NoSQL系统之间的一些差异将随着时间的推移而消失。已经有许多SQL数据库接受JSON文档作为本机数据类型并可以查询数据。某些数据库甚至具有对JSON数据施加约束的本机方法，因此它与传统的行和列数据一样严格对待。另一方面，NoSQL数据库不仅增加了类似于SQL的查询语言，还增加了传统SQL数据库的其他功能，例如MongoDB的ACID属性。一种可能的路径是，未来几代数据库以及当前数据库系统的未来版本将跨越这些范例并提供SQL和NoSQL功能，从而有助于保持数据库世界不那么碎片化。例如，Microsoft的AzureCosmosDB在底层使用一组原语来交替地重现两个系统的行为。GoogleCloudSpanner结合了SQL的强一致性和NoSQL系统的水平可扩展性。然而，纯SQL和纯NoSQL系统在未来许多年仍将占有一席之地。在设计灵活性、横向可扩展性和高可用性比强读取一致性和其他SQL数据库通用的保护措施更重要的情况下，请考虑使用NoSQL。对于许多应用程序，这些安全措施可能值得为NoSQL提供的功能进行权衡。对于许多应用程序来说，为了NoSQL的独特优势而牺牲这些安全措施是值得的。
