“Not Only SQL”的由来在于，不久前，当你有一些数据要存储时，唯一的问题是“Oracle 还是 Microsoft？” 没有人想过 SQL RDBMS 是否真的是存储数据的最佳解决方案。使用 Oracle 或 SQL Server 以外的东西简直是不可想象的。
“Not Only SQL”背后的理念正是它所说的：当您选择如何存储数据时，您不仅要考虑 SQL，还要考虑其他可能性。这个想法是您分析数据并选择最适合数据的存储解决方案。如果您的数据是对象形的，则使用对象存储；如果您的数据是文档形的，则使用文档存储；如果您的数据是 XML 形的，则使用 XML 存储；如果您的数据是图形，则使用使用图形数据库，如果你的数据是树形的，你使用树形数据库，如果你的数据看起来像一个扁平的键值结构，你使用键值存储，如果你想存储时间序列数据，你使用一个时间序列数据库，……如果你的数据是矩形表格的关系数据，那么一定要使用 RDBMS。
TL;博士
数据库系统之间的主要区别不是用于查询数据库的语言，而是系统的一致性模型。维恩图应该是两个相交的集合——SQL 不是 NoSQL 的正确子集，而是它自己的数据访问语言，可能会或可能不会被其他技术补充。SQL 将是数据库查询语言的适当子集。
有 NoSQL、OldSQL 和 NewSQL。
NoSQL曾经意味着“不是 SQL”，但现在（更多）可能意味着“不仅仅是 SQL”——因为许多 NoSQL 系统的提供者正在（试图）在其键值（KV）上附加/移植 SQL 接口)、文档或图形存储。
OldSQL 系统本质上是主要的 RDBMS 供应商的产品（Oracle、SQL Server、Sybase、PostgreSQL、MySQL...）。在本演示文稿(.pdf) 的第 13 页上，Michael Stonebraker声称表明 OldSQL 仅花费 4% 的时间做“有用”的工作 - 也可在此处找到：
他的论点是应该在不同系统之间拆分 OLTP 工作和 OLAP 工作 - OLTP 应该通过不共享的分片架构来完成，例如他自己的系统VoltDB，而 OLAP 应该由列式存储完成（另见这里) 类型架构（例如Vertica，他也曾在其中扮演过角色）。值得注意的是，Stonebraker 不仅在商业领域非常成功，而且在学术界也非常成功，并且获得了图灵奖——计算机科学的“诺贝尔奖”！
NewSQL是（恕我直言）最有趣的系统，可以像从 OldSQL 的灰烬中重生的凤凰一样（形象地说）。他们的USP是他们是HTAP系统（混合交易和分析处理）。
这些分布式系统可以同时支持 OLAP 和 OLTP 查询，因为数据分布在多个节点上——这些节点可以在同一个机架、数据中心或大陆上和/或全球分布在云提供商之间，以增加弹性和冗余 - 预计您在正常运行时间供应中添加的每个小数“9”的成本都会增加一个“0” 。
他们使用共识算法（通常是Raft或Paxos）来协调节点的数据，并且分片是透明的——即使对系统的 DBA 也是如此。此类系统的三个示例是CockroachDB、TiDB和YugaByte。
有趣的是，这些系统虽然取得了一定程度的成功，但还不是（还？）家喻户晓的名字。“大男孩”正在反击，将柱状存储和 KV 产品用螺栓/嫁接到他们自己的系统上。在这场辩论中特别感兴趣的是，这些系统本身位于 KV 存储的“顶部”（通常是 RocksDB - 尽管 CockroachDB 正在开发自己的 Go语言 Pebble）。PostgreSQL 还有文档 (JSONB) 和KV 存储。
为了回答这个问题，系统之间真正的区别特征不是用于查询数据的接口（可以而且确实范围从直接 C 语言编程（命令式）到 SQL（声明式） - 及其风格/改编），而是事务一致性模型。
这些模型要么是ACID（一致）vs. BASE（可用），关键是这些系统在 CAP 定理方面的适合位置。此外，KV 存储可以支持部分或全部ACID 事务特性。
OldSQL 和 NewSQL 重视一致性高于一切（CAP 系统下的“CP”）——他们的论点是，例如，结果不一致的银行系统是灾难的根源（真的！）。
然而，NoSQL 爱好者会建议，并非所有系统都需要铸铁一致性。例如，使用 BASE 数据库（CAP 术语中的“AP”）从亚马逊订购一本书 -可能（显示的库存水平不正确）会延迟几天，甚至取消 - 但好处是查询速度更快，操作更容易（没有共识要维持）。
这就是区分数据库系统的症结所在——“CP”或“AP”！CP 将始终为您提供正确答案（大多数节点仍然可用）或不提供答案，而 AP 系统通常会响应（即使只有一个节点启动）但您的答案可能没有考虑其他节点的数据更新响应（即它们之间的网络链接断开......）。
我希望这是一个令人满意的“第一次通过”答案——这是一个很大的话题，对于 db 书呆子来说，绝对令人着迷。我会敦促您阅读它（Wiki 是一个好的开始，但不能替代主要来源）。特别是，我建议您详细了解 CockroachDB 和 TiDB 的底层架构，看看它们如何在保持一致性的同时从一个节点分片和移动数据。
这里和这里有各种 NoSQL 系统的综合列表（最好的恕我直言）。这里还有一个人气评级网站（但要避免比较——他们只是重复系统网站上的宣传——通常已经过时了）。
最后一句话，有“混合模型”（或多模型）数据库（ArangoDB和OrientDB - 都有 F/LOSS 和 Enterprise 版本 - OrientDB 现在是 SAP 的一部分），但它们不是家喻户晓的名字是有原因的。ArangoDB 不支持 ANSI SQL，而是支持它自己的风格 - AQL ， OrientDB也不支持ISO SQL。
我使用过的最好的多模型数据库是 PostgreSQL，它具有如上所述的 KV 和文档存储。您可以使用 SQL 来查询这些并与“普通”表连接。正在向其中添加OpenCypher（一种开放的图形查询语言标准）的工作正在进行中（请参见此处和此处）。
最后，最后一句话：PostgreSQL 也有一个列存储扩展和一个时间序列扩展——这两者都是数据库系统的非常重要的（子）类。两个扩展都只是扩展而不是分叉——你可以使用带有这些扩展的“普通”SQL（即所有 PostgreSQL 标准兼容的 SQL）。
因此，我们可以看到，虽然 NoSQL 在某些情况下（但不是全部）（例如，许多系统设计人员乐于保持简单的 KV 存储）添加 SQL 功能，但 SQL 正在反击、采用和适应新的和/或更复杂的数据存储和检索要求——其中一些我什至没有涉及（GIS 系统......）。所以说 NoSQL 完全包含 SQL 将是一幅不完整的图景......
正如对问题本身的评论所指出的那样，SQL 标准现在处理非关系范式，这只会在未来增加！其他答案也解决了 - 值得一读（1和2）！
NoSQL 曾经、现在、并且永远都是一个模糊的流行语，而不是一个定义明确的术语。
它的起源与一个历史趋势有关：在本世纪初，如果你说“数据库”，假设你在谈论基于 SQL 的关系数据库，而“选择数据库”只是意味着选择哪种实现你正在使用的那种技术。作为“Web 2.0”和“云”技术运动的一部分，人们开始挑战这一假设，并使用完全不同的数据库系统——这些系统在当时不寻常地以“无 SQL”为特色。维基百科建议第一次使用“NoSQL”来指代这些是 2009 年。
该术语最初主要指的是基于文档的和键值数据库，因为当时很多人都在这样做；在快速发展的领域中，它是一个有用的包罗万象的工具。随着越来越多的想法被探索，这个术语变得更加混乱而不是有用 - 它涵盖的一些数据库除了不是 SQL 关系之外没有任何共同点。更糟糕的是，一些非关系型数据库开始添加 SQL 或类似 SQL 的查询语言；一些关系数据库开始添加功能，让您以混合非关系方式使用它们。
将“不”改造成“不仅”是一种使该术语再次有意义的可爱方式，但更好的想法可能是不使用它。它的唯一价值是提醒“数据库”不一定是“基于关系 SQL 的数据库”；使用诸如“数据存储”之类的其他术语可以达到相同的目的，而无需将所有内容都集中在事物与 SQL 的关系这一最不相关的问题上。
SQL 是一种语言。NoSQL 是一种选择数据库系统的方法。比较它们是没有意义的。
“Not Only SQL”的由来在于，不久前，当你有一些数据要存储时，唯一的问题是“Oracle 还是 Microsoft？” 没有人想过 SQL RDBMS 是否真的是存储数据的最佳解决方案。使用 Oracle 或 SQL Server 以外的东西简直是不可想象的。
“Not Only SQL”背后的理念正是它所说的：当您选择如何存储数据时，您不仅要考虑 SQL，还要考虑其他可能性。这个想法是您分析数据并选择最适合数据的存储解决方案。如果您的数据是对象形的，则使用对象存储；如果您的数据是文档形的，则使用文档存储；如果您的数据是 XML 形的，则使用 XML 存储；如果您的数据是图形，则使用使用图形数据库，如果你的数据是树形的，你使用树形数据库，如果你的数据看起来像一个扁平的键值结构，你使用键值存储，如果你想存储时间序列数据，你使用一个时间序列数据库，……如果你的数据是矩形表格的关系数据，那么一定要使用 RDBMS。
即使您的数据是关系数据，SQL 仍然不是唯一的选择。有非 SQL 关系数据库、超关系数据库、后 SQL 关系数据库（例如 Rel），还有诸如 NF² 之类的东西。所有这些都是关系的，但没有一个是 SQL。
有一种说法是 NoSQL 数据库不支持一致性，或者不支持事务。那是错的。首先，没有“NoSQL 数据库”之类的东西。NoSQL 不是一种数据库技术，它是一种选择数据库的方法。但是，即使我们查看通常称为“NoSQL 数据库”的数据库，我们也会看到实际上存在不同的数据库，它们具有许多不同的一致性和事务方法。例如，Datomic 提供类似 SQL 的 ACID 保证和事务。有些提供比 SQL 更高的保证。与 SQL 相比，有些提供宽松的保证。
有些提供灵活的、可配置的保证，允许您在不同维度的性能和保证之间进行选择。有时甚至针对不同的数据做出不同的选择。
因此， NoSQL 背后的真正想法只是分析您的需求并选择最适合您需求的解决方案。这里的所有都是它的。
实际上，到目前为止，这只是在谈论数据是如何存储的。如何查询数据确实是另一个问题。使用 SQL 查询许多“非 SQL”数据库是完全可能的。性能特征可能不同，但功能不会。同样，您可以使用 SQL 以外的语言查询“传统 SQL”数据库。事实上，在许多现代系统中，实际上并没有很多 SQL。例如，他们可能正在使用 LINQ 或 ORM。Ruby、Python、Perl、ECMAScript，许多其他编程语言都有用于数据库查询的内部和外部 DSL，例如 Ruby 中的 ARel。
现在的模式或以后的模式
NoSQL，恕我直言，用词不当。
NoSQL 是一个模式读取数据存储库。与之相反的是 RDBMS，它首先是模式。RDBMS 让设计人员有责任提出有效的数据结构，并减轻分析师的负担，分析师有定义的模式和约束来确保数据完整性。另一方面，NoSQL 需要最少的前期设计。它给数据分析师带来了负担，他们必须通过强加自己的结构和检查数据来处理数据结构的灵活性。
SQL 本身就是一种语言。SQL 可用于查询 NoSQL 存储库，就像它用于查询 RDBMS 一样。