【小资说库】第5期 OldSQL、NoSQL和NewSQL

在第2期数据库发展历史介绍中，我们介绍到数据库经历了人工管理阶段、文件系统阶段和数据库系统阶段，最终于上世纪70年代末发展进入了关系型数据库。时至今日，关系型数据库在风起云涌的数据库江湖依然占有重要地位。

在第3期的介绍中我们说到，SQL（Structured Query Language）及SQL标准围绕的是关系数据库。

随着计算机技术的发展，数据量的爆炸性增长，关系型数据库在海量数据的存储及并发读写上遇到了瓶颈，因此近些年涌现了NoSQL和NewSQL数据库。那么，什么是NoSQL数据库，什么是NewSQL数据库呢？这一期我们来尝试聊一聊。

SQL，NoSQL及NewSQL浅析

——关于什么是NoSQL及NewSQL，小编尝试查阅了一些材料。其中这篇CSDN博客中对OldSQL、NoSQL和NewSQL的对比做了较清晰的说明。以下内容主要转载自此博客，小编只是基于自己的理解，稍做了些文字整理。信息量有些大，大家耐心阅读。

一、关系数据库SQL，也叫OldSQL

关系数据库，是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。（编者注：有关什么是数据库关系模型，及如何构建这种关系模型即数据库建模，在很多数据库教材和书籍中都能了解到~~）

关系模型的常用概念

• 关系：可以理解为一张二维表，每个关系都具有一个关系名，就是通常说的表名。

    ——编者注：这也是为什么数据库使用过程中，会在一些返回信息中经常看到Relation身影的原因~~

• 元组：可以理解为二维表中的一行，在数据库中经常被称为记录。 

     ——编者注：Tuple、元组、记录，他们原来是同一身份（数据库表中的一行）的不同马甲。

• 属性：可以理解为二维表中的一列，在数据库中经常被称为字段。

     ——编者注：是的，列、字段、属性是数据库表中一列的不同马甲。 

• 域：属性的取值范围，也就是数据库中某一列的取值限制。 

• 关键字：一组可以唯一标识元组的属性，数据库中常称为主键，由一个或多个列组成。 

• 关系模式：指对关系的描述。其格式为：关系名(属性1，属性2， … … ，属性N)，在数据库中称为表结构。 
        

关系型数据库的优点：  

• 容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解。     

• 使用方便：通用的SQL语言使得操作关系型数据库非常方便。

• 易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率。

关系型数据库瓶颈

• 高并发读写需求：用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈。       

• 海量数据的高效率读写：  网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低。

• 高扩展性和可用性：在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。

  在关系型数据库中，导致性能欠佳的最主要原因是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性，我们必须尽量按照其要求的范式进行设计，关系型数据库中的表都是存储一个格式化的数据结构。每个元组字段的组成都是一样，即使不是每个元组都需要所有的字段， 但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行链接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。

          ——编者注：看来接下来的一期，我们有必要介绍ACID及数据库范式了~~

二、NoSQL

近些年蓬勃发展的NoSQL系统最初是宣称不再需要SQL的，但后来也不得不修正为Not Only SQL，意即”不仅仅是SQL”，来拥抱SQL。

NoSQL指的是非关系型的数据库。是对不同于传统的关系型数据库的数据库管理系统的统称。NoSQL用于超大规模数据的存储。

• 键值(Key-Value)存储数据库

  这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。举例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB。

• 列存储数据库。

  这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra, HBase, Riak。

• 文档型数据库

  文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。

• 图形(Graph)数据库：        

图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。如：Neo4J, InfoGrid, Infinite Graph。

因此，我们总结NoSQL数据库在以下的这几种情况下比较适用：            

• 数据模型比较简单；

• 需要灵活性更强的IT系统；

• 对数据库性能要求较高；

• 不需要高度的数据一致性；

• 对于给定key，比较容易映射复杂值的环境。

NoSQL的优势

• 易扩展

  NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

• 大数据量，高性能

  NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。同时NoSQL 数据库针对特定的数据模型（如文档、键值和图形）和访问模式进行了优化，这与尝试使用关系数据库完成类似功能相比可实现更高的性能。

• 灵活的数据模型

  NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。

• 高可用

  NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。

NOSQL的缺点以及一些挑战

• 已有key-value数据库产品大多是面向特定应用自治构建的，缺乏通用性；

• 已有产品支持的功能有限（不支持事务特性），导致其应用具有一定的局限性；

• 已有一些研究成果和改进的NoSQL数据存储系统，但它们都是针对不同应用需求而提出的相应解决方案，如支持组内事务特性、弹性事务等，很少从全局考虑系统的通用性，也没有形成系列化的研究成果；

• 缺乏类似关系数据库所具有的强有力的理论(如armstrong公理系统)、技术（如成熟的基于启发式的优化策略、两段封锁协议等）、标准规范（如SQL语言）的支持。

• 目前，HBase数据库是安全特性最完善的NoSQL数据库产品之一，而其他的NoSQL数据库多数没有提供内建的安全机制，但随着NoSQL的发展，越来越多的人开始意识到安全的重要，部分NoSQL产品逐渐开始提供一些安全方面的支持。

BASE原则以及CAP定理

BASE原则：

• Basically Availble –基本可用

• Soft-state –软状态/柔性事务。 “Soft state” 可以理解为”无连接”的, 而 “Hard state” 是”面向连接”的

• Eventual Consistency – 最终一致性， 也是是 ACID 的最终目的。

CAP定理：

在计算机科学中, CAP定理（CAP theorem）, 又被称作 布鲁尔定理（Brewer’s theorem）, 它指出对于一个分布式计算系统来说，不可能同时满足以下三点:

• 一致性(Consistency) (所有节点在同一时间具有相同的数据)

• 可用性(Availability) (保证每个请求不管成功或者失败都有响应)

• 分区容忍性(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。

因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：

• CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。

• CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。

• AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

详细请参见

总结

NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。 OldSQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上，NoSQL关注在存储上。

三、NewSQL

NewSQL 是一种新型关系数据库管理系统，是对各种新的可扩展/高性能数据库的简称，这类数据库不仅具有NoSQL对海量数据的存储管理能力，试图为联机事务处理(OLTP)读写工作负载提供与NoSQL系统相同的可伸缩性能，还保持了传统数据库支持ACID和SQL等特性。

因此，可以将典型NewSQL技术理解成分布式关系型数据库，能够支持分布式事务是一个基本前提。NoSQL与NewSQL在技术栈上有很多重叠，但在是否支持关系型模型及对复杂事务的支持力度上是存在明显区别的。

NewSQL分类

NewSQL系统虽然在的内部结构变化很大，但是它们有两个显着的共同特点：(1)它们都支持关系数据模型，(2) 它们都使用SQL作为其主要的接口。目前NewSQL系统大致分三类：

• 新架构：这一类型的NewSQL系统是全新的数据库平台，它们均采取了不同的设计方法。

• 数据库工作在一个分布式集群的节点上，其中每个节点拥有一个数据子集。 SQL查询被分成查询片段发送给自己所在的数据的节点上执行。这些数据库可以通过添加额外的节点来线性扩展。现有的这类数据库有： Google Spanner, VoltDB, Clustrix, NuoDB.

• 数据库系统通常有一个单一的主节点的数据源。它们有一组节点用来做事务处理，这些节点接到特定的SQL查询后，会把它所需的所有数据从主节点上取回来后执行SQL查询，再返回结果。

• SQL引擎：这一类是高度优化的SQL存储引擎。这些系统提供了MySQL相同的编程接口，但扩展性比内置的引擎InnoDB更好。这类数据库系统有：TokuDB, MemSQL。

• 透明分片：这一类系统提供了分片的中间件层，数据库自动分割在多个节点运行。这类数据库包括：ScaleBase，dbShards, Scalearc。

---------------------------------------------------------------------我是华丽丽的分割线---------------------------------------------------------------------

那在数据库选型时，如何在 SQL、NewSQL、NoSQL 之间进行取舍呢？下面两张图能很形象地帮助到你。

图片摘自：https://blog.csdn.net/defonds/article/details/48471087

图1 SQL vs. NewSQL vs. NoSQL

图2Do I Need SQL or Hadoop?