我认为您是在问RDBMS和非RDBMS系统之间有什么区别而不是具体的问题。但我会涵盖所有内容，所以请留在我身边，因为答案会很长，但相信我，阅读本文后一切都会变得清晰。
如果我们谈论存储结构的历史，首先想到的是文件。所以在年代，最广泛使用的存储结构是目录中的文件。这种类型的数据模型被称为层次模型。这种模型中的数据表示如下所示。
这里的数据存储在树状结构中。
这个模型有问题
应用程序设计为硬核模式，它广泛知道“电子”下有“电视”和“便携式电子”类别。在此模型上执行事务时一切正常，因为您的应用程序知道存储的类别和结构。但是假设现在需要在这个称为“手机”的存储结构中添加新的类别。在这样的事件中，整个应用程序代码将需要重组和重新编码，以使应用程序意识到现在它具有这个新类别以及可以执行哪些事务的事实。
事务是昂贵的，尤其是读事务。想象一下，搜索设备名称形成了一个TB的数据，但不知道该设备属于哪个类别。在这种情况下，必须遍历整个树才能找到匹配项。（时间随着数据的增加线性增加，这很糟糕。）
所有交易都必须进行硬编码。也就是说，如果应用程序想要提供对插入、删除和更新的支持，那么所有这些查询都必须由开发人员进行广泛的编程，以提供对特定存储结构的支持。
总之，对于开发人员来说，设计具有这种存储的系统极其困难，因为他们必须进行优化以实现性能。并且还需要对整个系统进行重组和记录，以防对现有存储结构/模式进行极小的修改。所以这些类型的系统是保守的改变。这让公司损失了数百万美元，因为维护这个东西非常困难。因此，这些问题导致了称为关系数据库系统的新系统的开发。
关系型数据库管理系统
关系数据库的设计使命是通过为开发人员提供一个抽象层来简化他们的生活。RDBMS的数据模型是表。这些表可以通过外键相互连接，因此可以在表上执行连接。表面还具有用于搜索记录的主键。最重要的方面是模式。Scheme只是数据库的一种设计，它显示了给定数据库中的所有表如何相互关联。并且它还定义了与表的每一列相关联的特定类型和约束等。所有事务支持均由数据库管理系统(DBMS)提供。一些流行的DBMS是Oracle、MySQL等。与这些表（数据库）的交互（事务）可以使用称为SQL的非常简单的声明性语言（类似英语）来执行。
因此，通过模式，RDBMS能够为开发人员提供一个抽象层。这种抽象是可能的，因为它限制了从数据库写入和检索数据的方式。例如，如果表的模式为(id,text,text,number,number)那么它将接受具有约束断言的相同格式的记录，如果应用程序不遵守，则它不会插入到数据库中给出一个例外。因此，存储在该系统中的数据干净、易于阅读且结构良好。结构良好是这里最重要的一点，因为现在系统了解它需要了解的所有数据，以便管理数据交易及其数据结构。因此，它可以针对各种系统进行通用设计。
RDBMS提供的优点：
抽象
ACID属性（保证数据的一致性、持久性、集成性和原子性）
以极其简单的查询语言提供事务支持。
对数据库模式的修改非常容易，并且节省了大量开发时间，因为应用程序不需要知道模式。（即幕后逻辑）换句话说，它为应用程序提供了与数据无关的层次。
所有事务都经过优化以提供最高性能。（使用“解释”查询来查看同一查询的执行流程将如何根据正在处理的数据量和数据类型而变化）
让我们不要忘记让开发人员的生活如此轻松。
它在行业中运行良好超过30年，每个人都知道我吨。
现在的主要问题是，如果这个系统如此出色，那么对非RDBM（所谓的No-SQL）有什么需要？
RDBMS也有缺点。
RDBMS不可扩展。（从技术上讲，有一些解决方案叫做Teradata，MySQL的数据库系统，但这些解决方案仍然非常昂贵，而且当数据超过GB时间性能仍然很差。）而在现代，现在一个PB系统上产生PB级数据时，GB非常小。小时期。道德是，一旦每个表的数据超过10GB，开源解决方案就不会做得很好。搜索很慢，所有其他交易都很慢。
许多应用程序不能有任何方案。应用程序的数据模型不能根据连接表来定义。例如，语言矩阵或人的个性/特征等等。（并不是说这不能作为表格，但这样做时总会有重大的权衡，因为这样做可能会丢失必要的信息或信息的有效性可能会下降）
当涉及到大量数据时，对该系统的分析很糟糕。想象一下有列的时候，您需要获得1列的平均值。它需要读取整个数据库才能做到这一点。（即，每次查询DB所有的单个记录时都会检索所有列，因为这些记录存储在磁盘上的块中，并且在查询时将检索整个块。）想象一下只有1TB拿到数据并对其进行平均，如何从磁盘读取它需要多长时间？并且正在执行的操作非常简单，但是想象执行复杂的操作。
在现代世界中收集或产生的数据的结构并不像RDBMS所希望的那样。
这个系统不支持图像数据和视频数据存储。（我知道这是可能的，但你知道它的表现，所以我们就说不）
数据库设计决策和模式很难设计，在某些情况下可能需要数年时间才能设计。
并非每个人都了解架构，因为我在行业中经常看到，没有人记录基于架构决策和数据库设计决策的证据。（新员工的情况）
所以需要一个不是RDBS和60年代树状的新系统。而这些新系统被称为No-SQL。奇怪的是，他们将其命名为No-SQL而不是No-relational。因为SQL只是一种语言，与关系DBMS的实现方式无关。
有了No-SQL，就不再需要模式来存储数据。现在，应用程序可以在数据库中存储任何类型的数据，并且它旨在处理大型非结构化数据。前几个流行的系统是什么MapReduce、CouchDB、MongoDB和Hadoop等。某些系统专门针对OLAP而不是OTLP。（简而言之，它们更面向分析而不是面向事务）
好处：
最终的一致性（如果你不知道这意味着什么，或者如果有足够多的人要求，将来会具体说明。）
系统具有高度的可扩展性，旨在扩展和运行0一PC。（许多系统将计算转化为数据，而不是将数据转化为计算，例如mapreduce）
不需要模式。能够轻松存储大型非结构化数据。
表现很好。（每个系统都具有特定类型的性能。例如分析性、事务性等）
缺点：
没有架构。（可能是福音也是祸根）
项目和应用程序之间不会保持标准。因此，如果所有应用程序都是用RDBMS设计的，那么应用程序就知道无论在哪里查询，它都会返回一些关系数据，而在No-SQL系统中则不然。
程序员有责任确保各种查询的性能和优化。（虽然有优化的系统，但很多没有像RDBMS优化的那样优化）
MongoDB
MongoDB是面向文档的No-SQL数据库。MongoDB中的文档与称为JSON数据表示与技术密切相关。JSON数据易于解析和处理。下面给出了MongoDB文档的示例。
MongoDB是在7年创建的，然后经过多年的改进。最近MongoDB因此对SQLlike语言的支持而变得非常流行。大数据工具中的解决方案非常困难，尤其是MapReduce，因为公司没有资源来编程和维护新技术。（当然，MapReduce使程序员的工作变得容易，但仍然不是所有的程序员都能使用它来获得最大的效用）
如今，大数据被认为是炒作。每个人都想使用它，但没有人知道如何使用它。他们缺乏使用它所需的技能。MongoDB提出的解决方案帮助许多公司实施和使用大数据技术，比如我之前提到的SQL之类的查询语言支持。（当然，MongoDB对许多有些事情，我同意这一点，但您也必须将此因素视为成功因素）
如您所见，MongoDB中的存储是面向文档的，并且没有与文档相关联的特定模式和结构。任何东西都可以添加到文档中。但是这里程序员必须确保在所有文档中维护某种类型的标准和结构，以便可以对记录进行基本查询。
要使用SQL在RDBMS重新创建数据库，您将执行以下操作。
创建数据库我的数据库；
猜猜在MongoDB中你会喜欢什么
使用我的数据库；
看看它有多简单？现在我不会谈论所有不同的查询并进行比较，你可以谷歌它并与SQL进行比较。
好处
高度可扩展
数据复制得到照顾
最终一致性
提供大数据解决方案，简单易用
没有方案
很棒的表演
良好的文档和支持
数据库管理员不必花时间设计模式。因此节省了时间和金钱。
缺点：
开发人员必须确保在整个数据库中维护某些结构。
使用大量内存。与其他SQL系统相比，在某些方面较慢。
希望现在你能很好地理解这些系统。