究竟什么是非结构化数据，为什么要使用非关系 DBMS？

不幸的是， NoSQL数据库系统何时优于RDBMS的答案有点主观，这就是为什么它受到高度争论的原因。许多错误信息导致了NoSQL数据库比RDBMS更快的错误含义，尤其是对于大数据而言，这不一定是正确的。这种内涵是基于拥有大数据的公司使用NoSQL数据库的起源故事他们实际上试图解决扩展问题，但不是因为扩展性能，而是因为灵活性之一，让他们作为开发人员/基础设施管理员能够更快地扩展。（在我看来，随着现代云服务和 Azure 和 AWS 等解耦服务的出现，这个问题现在主要以另一种方式解决。）但直到今天，同样的公司，比如Facebook ，仍然使用RDBMS。到NoSQL数据库系统，对于可能相似数量的数据，因为这不是数据库性能的问题，而是灵活性以及根据用例使用正确的工具来完成正确的工作的问题。

如前所述，在较高的层次上，NoSQL数据库在一致性方面具有灵活性的优势，这是在ACID 数据库主体之间为最终一致性进行的权衡。这种灵活性允许NoSQL数据库存储非结构化、半结构化和高度可变的结构化数据；并且它允许在跨多节点数据库集群水平扩展时轻松分布该数据库。由于它可以存储的数据架构的灵活性，它不必担心架构多节点集群中一个节点与另一个节点的变化。此外，由于它具有最终一致性的能力，它通常不必担心集群中的每个节点都有 100% 的相同数据。

由于其水平扩展的灵活性，人们可以松散地争论（在高层次上）这是使用NoSQL而非传统RDBMS时性能优势的来源。但其他权衡是当您处理NoSQL数据库时，由于缺乏一致的模式，您转换和查询数据的能力变得有限。我想保持客观，所以我认为 MongoDB 提供了多种查询数据的方法，我相信这些方法在设计上也更具程序性，因此对于不是很有经验的开发人员来说可能有点用户友好与传统的关系逻辑。但在保证最终一致性的情况下，只能做这么多充其量与 RDBMS 的实际保证一致性相反。

就NoSQL数据库的实际用例而言，它在很大程度上取决于数据的模式（或缺乏数据模式）以及开发人员的特定用例和他们需要支持的查询类型。您阅读的一些示例是潜在的用例，例如一个Email示例。Emails就我所定义的而言，它们在模式中是半结构化的。它们有一些一致的字段，如From, SentDateTime, ReceivedDateTime, ，Subject但它们都有高度可变的字段，如To,和。因此，NoSQL数据库在您将执行的查询类型具有仅依赖于和/或的谓词的情况下可能是有意义的CCBCCBodyFromSentDateTime场地。这些将是您在Emails table中的键，而Bodymessage 和Tofield 将是存储在table中的实体的其余部分（可能是JSON格式） 。（请注意，术语表在这里用于概念化。）

现在你当然是对自己说“但你可以在RDBMS中完成同样的事情”——这是真的，但NoSQL的灵活性及其最终的一致性再次允许你使用上面的示例表并将其分片到多个水平缩放时节点更容易。因此，即使NoSQL数据库的一些主要特性在传统RDBMS中也可用（从某种意义上说，我几乎认为NoSQL从特性的角度来看是RDBMS的一个子集），但它的灵活性和它必须遵循的规则与传统的 RDBMS 有很大的不同关系型数据库管理系统，让它在我们生活的世界中占有一席之地。

话虽如此，随着时间的推移发生了很多变化，即使是最初意义上的NoSQL系统也发生了很大变化，并适应了数据库世界的发展（或那些尚未消亡的系统）。NoSQL和RDBMS之间的界限继续模糊（为了更好），因为两者都在增长以适应它们从一个或另一个中丢失的东西。例如，现在存在符合ACID的NoSQL数据库，并且还存在具有更容易水平扩展功能的RDBMS数据库。