NoSql的优势在哪里，NoSql是什么

NoSql的优势

数据是当今世界最有价值的资产之一。在大数据时代，人们生产、收集数据的能力大大提升，但是传统的关系型数据库在可扩展性、数据模型和可用性方面已远远不能满足当前的数据处理需求，因此，各种 NoSQL 数据库系统应运而生。

1. NoSQL 数据库不像关系型数据库那样都有相同的特点，遵循相同的标准。NoSQL 数据库类型多样，可满足不同场景的应用需求，因此取得了巨大的成功。
2. NoSQL 数据库基本理念是以牺牲事务机制和强一致性机制，来获取更好的分布式部署能力和横向扩展能力，创造出新的数据模型，使其在不同的应用场景下，对特定业务数据具有更强的处理性能。
3. NoSQL 数据库最初是为了满足互联网的业务需求而诞生的，互联网数据具有大量化、多样化、 快速化等特点。
4. 在信息化时代背景下，互联网数据增长迅猛，数据集合规模已实现从 GB、PB 到 ZB 的飞跃。数据不仅仅是传统的结构化数据，还包含了大量的非结构化和半结构化数据，关系型数据库无法存储此类数据。

因此，很多互联网公司着手研发新型的、非关系型的数据库，这类非关系型数据库统称为 NoSQL 数据库，其主要优势如下

灵活的数据模型

• 互联网数据如网站用户信息、地理位置数据、社交图谱、用户产生的内容、机器日志数据以及传感器数据等，正在快速改变着人们的通信、购物、广告、娱乐等日常生活，没有使用这些数据的应用很快就会被用户所遗忘。开发者希望使用非常灵活的数据库，容纳新的数据类型，并且不会被第三方数据提供商的数据结构变化所影响。

• 关系型数据库的数据模型定义严格，无法快速容纳新的数据类型。例如，若要存储客户的电话号码、姓名、地址、城市等信息，则 SQL 数据库需要提前知晓要存储的是什么。这对于敏捷开发模式来说十分不方便，因为每次完成新特性时，通常都需要改变数据库的模式。

• NoSQL 数据库提供的数据模型则能很好地满足这种需求，各种应用可以通过这种灵活的数据模型存储数据而无须修改表；或者只需增加更多的列，无须进行数据的迁移。

可伸缩性强

• 对企业来说，关系型数据库一开始是普遍的选择。然而，在使用关系型数据库的过程中却遇到了越来越多的问题，原因在于它们是中心化的，是纵向扩展而不是横向扩展的。这使得它们不适合那些需要简单且动态可伸缩性的应用。

• NoSQL 数据库从一开始就是分布式、横向扩展的，因此非常适合互联网应用分布式的特性。

• 在互联网应用中，当数据库服务器无法满足数据存储和数据访问的需求时，只需要增加多台服务器，将用户请求分散到多台服务器上，即可减少单台服务器的性能瓶颈出现的可能性。

自动分片

• 由于关系型数据库存储的是结构化的数据，所以通常采用纵向扩展，即单台服务器要持有整个数据库来确保可靠性与数据的持续可用性。这样做的代价是非常昂贵的，而且扩展也会受到限制。针对这种问题的解决方案就是横向扩展，即添加服务器而不是扩展单台服务器的处理能力。

• NoSQL 数据库通常都支持自动分片，这意味着它们会自动地在多台服务器上分发数据，而不需要应用程序增加额外的操作。

自动备份

• NoSQL 数据库支持自动复制。在 NoSQL 数据库分布式集群中，服务器会自动对数据进行备份，即将一份数据复制存储在多台服务器上。因此，当多个用户访问同一数据时，可以将用户请求分散到多台服务器中。

• 同时，当某台服务器岀现故障时，其他服务器的数据可以提供备份，即 NoSQL 数据库的分布式集群具有高可用性与灾备恢复的能力。

NoSQL具体分析

NoSQL的概念

随着web2.0的快速发展，非关系型、分布式数据存储得到了快速的发展，它们不保证关系数据的ACID特性（原子性、一致性、隔离性、持久性，一个支持事务的数据库，必需要具有这四种特性，否则在事务过程当中无法保证数据的正确性）。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”，“Not Only SQL”也被很多人接受（“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字）。NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列存储、图型数据库、xml数据库等。

为什么要使用NoSQL数据库

1. 对数据库高并发读写的需求
   web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。

2. 对海量数据的高效率存储和访问的需求
   类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

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

NoSQL可以干什么

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

2. 大数据量高性能
   NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

3. 多样灵活的数据模型
   NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。

传统RDBMS VS NOSQL

RDBMS

• 高度组织化结构化数据
• 结构化查询语言（SQL）
• 数据和关系都存储在单独的表中。
• 数据操纵语言，数据定义语言
• 严格的一致性
• 基础事务

NoSQL

• 代表着不仅仅是SQL
• 没有声明性查询语言
• 没有预定义的模式
• 键 - 值对存储，列存储，文档存储，图形数据库
• 最终一致性，而非ACID属性
• 非结构化和不可预知的数据
• CAP定理
• 高性能，高可用性和可伸缩性

NoSQL数据模型简介

传统数据库模型和NoSQL数据模型对比

以一个电商客户、订单、订购、地址模型来对比下关系型数据库和非关系型数据库

1. 传统模型（ER图）
   

2. NoSQL（聚合模型例如Bson）

{
 "customer":{
   "id":1136,
   "name":"Z3",
   "billingAddress":[{"city":"beijing"}],
   "orders":[
    {
      "id":17,
      "customerId":1136,
      "orderItems":[{"productId":27,"price":77.5,"productName":"thinking in java"}],
      "shippingAddress":[{"city":"beijing"}]
      "orderPayment":[{"ccinfo":"111-222-333","txnid":"asdfadcd334","billingAddress":{"city":"beijing"}}],
      }
    ]
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

总结

• 传统关系模型：元组（行）是受限的结构，只能包含一系列的值，不能嵌套另外的元组和列表。所有操作都以元组为目标，而且其返回值必须是元组。适用于多种查询条件获取数据的需求。
• 聚合模型：是NoSQL操作数据时所用的单元，其结构比元组复杂，这种结构可以存放列表或嵌套其他记录。聚合数据模型的特点就是把经常访问的数据放在一起（聚合在一块），这样带来的好处很明显，对于某个查询请求，能够在与数据库一次交互中将所有数据都取出来。

四种聚合模型

1. KV键值
   特点：Key-Value模式。在这种数据结构中，数据表中的每一个实际行只具有行键（Key）和数值(Value)两个基本内容。值可以看做一个单独的存储区域，可能是任何类型，甚至是数组。

2. bson
   特点：与键值存储模式有相似性，但其值一般是半结构化内容，需要通过某种半结构化标记语言进行描述。和键值模式相比，文档式存储模式强调可以通过关键词查找查询文档内部的结构，而非只通过键来进行检索。文档允许嵌套，因此可以将传统关系型数据库中需要Join查询的字段整合为一个文档，这种做法理论上会增加存储开销，但是会提高查询效率。在分布式系统中，Join查询的开销较大，文档式嵌套存储的优势更加明显。

3. 列族
   特点：可以称为面向列的存储模式，以区别于关系型数据中面向行的存储模式，这种存储模式主要用在OLAP,数据仓库等场合。面向行的存储模式中，数据以行（或记录）的方式整合到一起，数据行中的每一个字段都在一起存储。但在面向列的存储模式中，属于不同列或列族的数据在不同的文件中，这些文件能分布在不同的位置上，甚至是不同的节点上。（简单结构如下图）
   

4. 图形
   特点：图存储模式来源于图论中的拓扑学。图存储模式是一种专门存储 节点和边以及节点之间的连线关系的拓扑存储方法。节点和边都存在描述参数，边是矢量，即有方向的，可能是单向或双向的。拓扑图中般需要记录如下内容: 节点(或称顶点)的ID和属性，节点之间的连线(或称边、关系),边的ID、方向和属性(例如转移函数等)。常见的点线拓扑关系有网页之间的链接关系，社交网络中的关注与转发关系等。如下图为某社交网络关系图模型。
   

NoSQL数据库四大分类及区别

四大分类

1. KV存储数据库

• 典型代表
  BerkeleyDB、MemcacheDB、Redis
• 特征
  可以通过key快速查询到value。一般来说，存储不需要考虑value的格式。

2. 文档存储数据库

• 典型代表
  MongoDB、CouchDB
• 特征
  文档数据库一般用类似json的格式存储，存储的内容是文档型的。这样也就有机会对某些字段建立索引，实现关系数据库的某些功能。

3. 列存储数据库

• 典型代表
  Hbase、Cassandra、Hypertable
• 特征
  按列存储数据，最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有着极大的IO优势。

4. 图关系数据库

• 典型代表
  Neo4J、FlockDB
• 特征
  图形关系的最佳存储，使用传统关系数据库来解决的话性能低下，而且设计及其不方便。

区别

NoSQL数据库中CAP+BASE原理

传统关系型数据库ACID原理

1. 原子性（Atomicity）
   一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有被执行过一样。

2. 一致性（Consistency）
   在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作

3. 独立性（Isolation）
   数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交、读已提交、可重复读和串行化。

4. 持久性（Durability）
   事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

CAP原理

1. 强一致性（Consistency）
   在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

2. 可用性（Availability）
   每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。

3. 分区容错性（Partition tolerance）
   分区容错性其实是约束了分布式系统需要具有如下的特性：分布式在遇到任何网络分区故障的时候，仍然需要保证对外提供满足一致性和可用性的服务，除非整个网络均已瘫痪。也就是说，它容忍错误的出现，在发生错误的情况下可以继续进行操作。

CAP的三进二原则

1.CAP理论的核心

一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类

• CA：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
• CP：满足一致性，分区容忍性的系统，通常性能不是特别高。
• AP：满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
  

2.如何选择

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。一致性和可用性的抉择可以参考思路

• 数据库事务一致性需求
  很多web实时系统并不要求雅阁的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高 。允许实现最终一致性。
• 数据库的写实时性和读实时性的需求
  对系统数据库来说，插入一条数据之后立刻查询，是肯定可以独处这条数据。但是对于大多数web应用来说，并不要求这么高的实时性，当我们发布一条消息后，过上几秒或是几十秒后被接受看到都是被允许的（如发微博/直播等，都是具有延迟的）
• 对复杂的SQL查询，特别是多表关联查询的需求
  任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询。我们把这些数据进行整合以k-v键值对的形式放到缓存里面，避免了数据库查询，这样子记得到我们所要的内容，又不给数据库增加负担，这样增强了数据的高可用。

BASE原理

BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。他的思想就是通过让系统在某一时刻牺牲数据一致性的要求来换取系统整体的伸缩性和性能上的改观。（也就是说牺牲C 来实现AP，以BASE的理论来达成最终一致性）。

1. 基本可用（Basically Available）
   这里是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心功能或者当前最重要功能可用。对于用户来说，他们当前最关注的功能或者最常用的功能的可用性将会获得保证，但是其他功能会被削弱。

2. 软状态（Soft state）
   允许系统数据存在中间状态，但不会影响到系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步时存在延时。

3. 最终一致（Eventually consistent）
   要求系统数据副本最终能够一致，而不需要实时保证数据副本一致。最终一致性是弱一致性的一种特殊情况。最终一致性有5个变种：因果一致性，读己之所写（例如发微博的时候，自己可以马上看到，但是粉丝要过几秒钟），会话一致性，单调读一致性，单调写一致性。