SQL和NoSQL分别代表两种很常见的数据库类型。SQL代表结构化查询语言，主要是用在关系型数据库管理系统中。NoSQL指的是“没有SQL”（不使用SQL来查询）或者不仅仅是SQL（使用SQL和非SQL查询方式）两种的区别包括创建方式、结构、存储的数据类型和数据的存储和查询方式。

关系型数据库使用含有严格的列、行的表结构。每行包含一条数据信息，每列包含特定的一类信息。保存的数据必须标准化，减少数据冗余提高可靠性。SQL是由美国国家标准协会(ANSI)和国际标准组织(ISO)支持的一种高度受控的标准。

非关系型数据库经常以NoSQL系统来实现。不是只有一种类型的NoSQL数据库，包含不同的模式：从key-value存储到文档存储和图数据库，时序数据库以及宽列存储。一些NoSQL系统还支持多模型，意味着它们可以在内部支持多个数据模式。

与用于SQL标准的ANSI/ISO流程不同，NoSQL系统没有相关的行业标准。支持各种NoSQL模式的确切方式取决于各个软件开发人员。NoSQL数据库的实现可能存在很大的差异，而且不兼容。例如，即使两个系统都是键值数据库，它们的API、数据模型和存储方法可能是高度不同的，并且相互不兼容。

NoSQL系统不依赖也不支持表连接。

SQL和NoSQL的区别

什么时候使用这两种数据模型？

NoSQL和SQL的性能比较是基于一致性、可用性和速度等属性。企业的需求通常决定使用哪种类型的数据库系统。

关系型(SQL)数据库非常适合处理易于理解、不经常更改、需要遵守严格的国际标准的数据模型，以及重视数据一致性甚于事务速度的业务。

非关系型数据库使用场景：数据经常发生变化，随着标准和API变化，需要处理多种类型的数据和高流量。

SQL和NoSQL数据库

流行的关系(SQL)数据库包括:

• IBM DB2
• Oracle数据库
• 微软SQL Server
• MySQL
• Postresql
  流行的非关系(NoSQL)数据库包括:
• Apache Cassandra
• HBase
• MongoDB
• Redis
  常见的NoSQL数据库类型包括:
• Key-value存储：使用简单的索引键和值存储数据。例如Oracle NoSQL数据库，Redis, Aerospike, Oracle Berkeley DB, Voldemort, Amazon DynamoDB和Infinity DB。
• 宽列存储：使用表、行和列。但是，列的格式和命名可以在同一表的不同行中有所不同。如Apache Cassandra、Scylla、Datastax Enterprise、Apache HBase、Apache Kudu、Apache Parquet、MonetDB等。
• 文档数据库：键-值模型的更复杂和结构化版本，它为每个文档提供自己的检索键。示例包括Orient DB、MarkLogic、MongoDB、IBM Cloudant、Couchbase和Apache CouchDB。
• 图数据库：以逻辑图的形式表示相互关联的数据。例如Neo4j, JanusGraph, FlockDB和GraphDB。

多模型数据库

现代数据库的一个主要趋势是支持多个数据模型。例如，既支持传统SQL又支持一个(或多个)NoSQL模式的系统。其他系统可能支持多个NoSQL数据模型，但不支持SQL。组合是无数的。

例如，Cassandra和Scylla虽然被归类为宽列存储，但也很容易支持键-值方式。此外，通过JanusGraph等附加组件，这三个NoSQL系统也可以支持图形数据库模式。在另一个例子中，Amazon DynamoDB虽然起源于键值存储，但也可以作为文档数据库使用。

JSON在NoSQL和SQL中

JSON (JavaScript Object Notation)是一种封装数据的格式，比如当数据从服务器传输到web应用程序时。它最常用于面向文档的数据库。

JSON是一种简单且轻量级的格式，易于读和写。随着非关系数据库、基于web的API和微服务的兴起，许多开发人员喜欢JSON格式。但是，它也可以用于在其他数据库(SQL和NoSQL)之间解析、存储和导出数据。

JSON让程序员可以轻松地跨系统交互数据集、列表和键值映射。JSON中的数据格式使用以下形式:

• Object：无序的name/value集合。
• Array：值的有序集合。
• Value：字符串，数字，true/false/null，对象和数组
• String：遵循编码标准的字符序列。
• Number：java数字例如：byte，short和long
  JSON的简单性受到应用程序开发人员的欢迎，他们更喜欢JSON而不是更复杂的XML序列化格式来传输数据。JSON在敏捷环境中也能很好地工作，因为JSON允许高效地使用数据。

这在关系和非关系数据库中都产生了对JSON特性的需求。

表join

表连接：基于SQL数据库中匹配的列来连接表。通过称为外键在表之间创建关系。

为了理解数据块之间的关系，SQL连接将来自多个表的数据组合在一起。例如，查看客户的订单历史记录。客户表和订单表的连接将在一个客户和他们的所有订单之间建立关系。
连接类型和连接命令取决于查询检索的记录。连接类型只能在数据加载到关系数据库后使用。
表连接有五种类型:
1、内连接
2、左连接
3、右连接
4、完全连接
5、交叉连接
当一个表可以连接到它自己时，还有一个自连接。用于连接操作的命令如下:

• 哈希连接
• 排序合并连接
• 嵌套循环连接

标准化数据和非标准化数据

标准化数据和非标准化数据的区别在于存储和检索数据的方法。

非标准化数据合并在一个表中。这加快了数据检索，因为查询不必像在标准化过程中那样搜索多个表来查找信息。所有东西都在一个地方，但是数据可能会被复制。增加的速度是以更多的数据冗余和更少的数据完整性为代价的。
这是一个非标准化数据库的样子:

标准化数据存储在多个表中。一种类型的数据组织在一个表中。相关数据存储在另一个表中。然后使用表连接，连接表之间的关系。标准化数据的好处包括减少冗余、更好的一致性和更高的数据完整性。但是这种做法会产生较慢的结果，特别是在需要处理大量数据的复杂查询时。

在标准化数据库中，没有重复的字段或列。重复字段将与非标准化数据库表中的键一起放入新的数据库表中。
这是规范化数据库表的样子:

其他区别：

标准化特点

• 常用于在线事务处理系统中
• 强调更快的插入、删除和更新
• 保持数据的完整性
• 消除冗余数据集
• 增加表和连接的数量
• 优化磁盘空间

非标准化特点

• 用于在线分析SQL系统和很多NoSQL系统
• 强调更快的搜索和分析
• 难以保持数据完整性
• 增加冗余数据
• 减少表的数量，并可以减少或消除连接
• 由于相同的数据存储在不同的位置，浪费磁盘空间
  数据库不必完全标准化或非标准化。有一个混合的选择。SQL数据库如果考虑速度，则可以通过删除一定数量的join来部分反规范化。如果考虑数据管理和冗余，可以在单独的表中规范化一部分数据。

有些情况需要去标准化。例如，对于具有运行多个join查询的大型表的应用程序，首选非标准化数据处理，因为创建标准化数据库的join可能非常昂贵和耗时。存储电子邮件、图像和视频等非结构化数据的应用程序也更适合去标准化。

强一致性和最终一致性

一致性是指每次发出相同请求时，数据库查询都返回相同的数据。强一致性意味着返回最新的数据，但由于内部一致性方法，它可能会导致更高的延迟。对于最终的一致性，查询结果不太一致，但它们更快，延迟更低。

最终一致性数据查询的早期结果可能没有最近的更新。这是因为跨数据库集群更新需要时间。

在强一致性中，数据在执行查询时被发送到每个副本。这会导致延迟，因为在更新副本时，任何请求的响应都必须等待。当数据一致时，将按照请求到达的顺序处理等待的请求，并重复此循环。

SQL数据库通常支持强一致性，这使得它们对于银行和金融行业中的事务性数据非常有用。

CAP理论

CAP定理解释了为什么分布式数据库在面对网络分区时不能同时保证一致性和可用性。这个定理说，一个应用程序只能同时保证以下三个特征中的两个:

• 一致性：所有请求得到都是最新数据
• 可用性：即时系统故障也能访问
• 分区容忍：即使有些节点无法通信，操作仍然保持完整
  为了更好的可伸缩性，一个折衷方案是：允许最终一致性。确定是否支持最终一致性是一个业务决策。

当一个应用放弃强一致性（在事务完成之前，系统中的每个数据副本都必须匹配）就变成最终一致性。这种妥协通常是为了系统更好的可扩展。这个决定是基于业务考虑的：对于每次写入数据都至关重要的情况，则需要强一致性。

云原生应用倾向于选择可用性和分区容忍性，而不是强一致性。这是因为云原生应用通常更愿意追求可扩展目标，而不是确保数据库节点始终处于通信状态。
虽然CAP定理中有三个元素，但主要是在两个元素之间权衡：可用性和一致性。第三个元素，分区容忍度，通常被认为是一种需求；您无法设计一个基于网络的分布式系统来避免分区状态，即使是暂时的。因此，分区容忍是可扩展性和弹性的必要条件，特别是对于NoSQL数据库。

ACID和BASE

ACID和BASE是数据库设计的模型。ACID模型有四个目标:

• 原子性：如果事务的任何部分没有执行成功，则整个操作将回滚。
• 一致性：确保数据库在每个事务中都保持结构完整。
• 隔离性：事务彼此独立地发生，并且对数据的访问是有节制的。
• 持久性：所有事务结果都永久保存在数据库中。
  满足这四个目标的关系数据库和一些NoSQL数据库(那些支持强一致性的数据库)被认为是符合acid的。这意味着事务完成后数据是一致的。
  然而，其他非关系型数据库转而使用BASE模型来实现规模和弹性。BASE代表:
• 基本可用：数据在大多数情况下都是可用的，即使在部分数据库中断的故障期间也是如此。数据被复制并分布在许多不同的存储系统上。
• 软状态：副本并不总是一致的。
• 最终一致： 数据将在某个时间点变得一致，但不能保证何时一致。
  BASE原则没有ACID那么严格。BASE中可用性高于其他原则，因为BASE用户最关心的是可扩展。像银行业这样需要数据可靠性和一致性的行业，依赖于符合acid的数据库。

分布式可扩展

垂直扩展关系数据库通常需要将其脱机，以便向服务器添加新的硬件。但是，即使到了缩减规模的时候，硬件也会保留下来。

分布式架构，扩展很容易。随着新节点添加到数据库集群中，性能将得到提高。这种扩展架构还添加了更多运行数据库副本的服务器。简单的点击鼠就可以缩放集群，以满足业务需求。

B-Tree和LSMT（日志结构合并树）

B树数据结构创建于近50年前，用于在对数时间内对数据进行排序、搜索、插入和删除。B树使用基于行的存储，允许低延迟和高吞吐量。许多SQL数据库使用传统的B树架构。该数据结构的一个新版本称为B+树，它将所有数据放在叶节点中，因此支持更大的扇出。B+树还支持数据元素和存储在RAM中的数据的有序链表。B+树在许多现代SQL和NoSQL系统中都使用。

日志结构的合并树(也称为LSM树)创建于20世纪90年代中期，以满足更大的数据集的需求。LSM树已经成为管理快速增长数据的首选方法，因为它最适合写容量大的数据。LSM树通常用于NoSQL数据库。

LSM树可以比B树甚至B+树更快地进行顺序写。因此，B树最适合不需要高写吞吐量的应用程序。LSM树是为高写吞吐量而设计的，但是它们比B树使用更多的内存和CPU资源。B+树可能比LSM树有更好的读性能。