注：此处为上课笔记
这里写目录标题
NoSQL
NOSQL(Not Only SQL)是对不同于传统的关系数据库的数据库管理系统的统称。
允许部分数据使用SQL系统存储，而其他数据允许使用NOSQL系统存储。其数据存储可以不需要固定的表格模式以及中介数据(metadata)，也经常会避免使用SQL的JOIN操作，一般有水平可扩展性的特征。
主要的四大类
- 键值存储数据库
- 列存储数据库
- 文档型数据库
- 图形数据库
NoSQL共同特征：
-
不需要预定义模式：
不需要事先定义数据模式，预定义表结构。
数据中的每条记录都可能有不同的属性和格式，当插入数据时，并不需要预先定义它们的模式； -
无共享架构：
相对于将所有数据存储的存储区域网络中的全共享架构，NoSQL往往将数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能； -
弹性可扩展：
-
分区：
相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区，将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能，又能保证没有单点失效的问题； -
异步复制：
和RAID存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。这样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延。缺点是并不总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据； -
BASE：
相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。
NoSQL适用情况：
1）数据模型比较简单：字段很多，而且外键很多，比如订单主表等
2）需要灵活性更强的IT系统：需求多变，表多变等
3）对数据库性能要求较高：读取或者更新压力高，瞬间并发高（限时抢购），关系数据库性能没有太多优势
4）不需要高度的数据一致性
理论
CAP理论
CAP解释为一致性（consistency）、可用性（availability）和分区容忍性（partition tolerance）。
上面三个性质不可能都做到
一致性：一个数据系统如何处理读写操作的一致性问题。分布式系统对于一致性的要求为当更新写入操作完成时，其余读取操作需要及时看到数据的更新；
可用性：一个系统能够持续不间断使用的问题。严格定义上的高性能可用性意味着一个系统从设计到实施都应该能够提供可持续的操作；
分区容忍性：如果分布式系统的部分断裂，形成一个一个孤立的分区，系统还能否提供服务。
BASE理论：
BASE思想实际上是CAP理论中AP的衍伸。
它通过牺牲高一致性，保证高可用性和分区容忍性。
BASE思想的组成有以下3个部分：
基本可用：首先完成基本工作
软状态：对数据一致状态的要求是“软”的
最终一致性：数据一致性最终是保证的
ACID和BASE：互相补充，而不是替代。
Basically Available(基本可用)
Soft State（软状态）
Eventually Consistent（最终一致性）
BASE是相对于DBMS中的ACID所提出来的新思想。
ACID理论
ACID指的是传统数据库对于数据特性的要求。
ACID属性保证了数据库的一致性，如银行系统中，付款就是一个事务。
ACID特性对于大型的分布式系统来说，与高性能是不兼容的。
如在线购买商品的时候，任何一个人购物的过程都为一个原子操作，不允许存在两个人同时进行购物的情况。
很明显对于绝大多数在线商城，这个方法并不适用。
- 原子性：即事务执行作为原子，不可再分离，整个语句要么执行，要么不执行，不可能停在中间某个环节；
- 一致性：在事务开始之前和事务结束之后，数据库的完整性约束没有被破坏；
- 隔离性：两个事务的执行互不干扰，也不会发生交互，一个事务不可能看到其他事务运行时中某一时刻的数据；
- 持久性：在事务完成以后，该事务对数据库所做的更改便持久地保存在数据库之中，并不会被回滚。
区别
四种主要详解
一丶键值存储数据库
键值存储典型实现的数据结构一般为数组链表：
先通过通过hash算法得出hashcode，
找到数组的某一个位置，
然后插入链表的第一个位置。
适用的场景
储存用户信息，比如会话、配置文件、参数、购物车等等。这些信息一般都和ID（键）挂钩，这种情景下键值数据库是个很好的选择。
不适用场景
1）取代通过键查询，而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径。
2）需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。
3）事务的支持。在Key-Value数据库中故障产生时不可以进行回滚。
Redis
一个开源的使用C语言编写的一个kv存储系统，是一个速度非常快的非关系内存数据库。它支持包括String、List、Set、Zset、hash五种数据结构。
二丶列存储数据库
列数据库是对应并区别于行数据库的概念。
行数据库就是我们所熟知的传统关系型数据库，即数据按记录存储，每一条记录的所有属性都存储在一起，如果要查询一条记录的一个属性值，需要先读取整条记录的数据。
而列数据库是按数据库记录的列来组织和存储数据的，数据库中每个表由一组页链的集合组成，每条页链对应表中的一个存储列，而该页链中每一页存储的是该列的一个或多个值。
适用的场景
1）日志。因为我们可以将数据储存在不同的列中，每个应用程序可以将信息写入自己的列族中。比如读取时间的日志
2）博客平台。我们储存每个信息到不同的列族中。举个例子，标签可以储存在一个，类别可以在一个，而文章则在另一个。
不适用场景
1）如果需要ACID事务。Vassandra就不支持事务；
2）原型设计。如果我们分析Cassandra的数据结构，我们就会发现结构是基于我们期望的数据查询方式而定。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。
Apache Cassandra
Cassandra 是一种开源列式数据库，专门处理多个商用服务器之间的大量数据。与关系数据库中的表不同的是，同一表中的不同行 (列系列) 不必共享相同的列集合。
Apache HBase
Apache HBase 是一种开源、列式、分布式 NoSQL 数据库。HBase 在 Apache Hadoop 框架中运行。HBase 为您提供了一种用列式压缩和存储方式来存储大量稀疏数据的高效容错方法。
三丶文档型数据库
键值型的值做了一定的约束
文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档、半结构化的文档以特定的格式存储，例如JSON。
文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值。而文档型数据库比键值数据库的查询效率更高，如：CouchDB，MongoDb。国内也有文档型数据库SequoiaDB，已经开源。
适用的场景
1）日志。企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以我们可以使用它储存不同的信息。
2）分析。鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量。
不适用场景
在不同的文档上添加事务。文档型数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案。
MongoDB
MongoDB是10gen公司研发的面向文档的开源的NoSQL数据库系统，用C++语言编写。
它提供一种强大、灵活、可扩展的数据存储方式。
它扩展了关系型数据库的众多功能，如辅助索引、范围查询和排序。
MongoDB的功能非常丰富，比如内置的对MapReduce聚合的支持，以及对地理空间索引的支持。
MongoDB的主要特性
- 数据类型丰富。MongoDB是面向文档的数据库，放弃关系模型的一个主要原因是为了获得更加灵活的扩展性。它是无模式的，文档的键不会事先定义也不会固定不变，应用层可以方便地处理新增的键或丢失的键，为开发者变更数据模型提供极大的便利；
- 功能丰富。支持辅助索引、存储JavaScript和MapReduce等其他聚合工具的独特功能；
- 容易扩展。MongoDB在设计时考虑了系统扩展的问题，面向文档的数据模型可以自动在多台服务器之间进行分割。通过其Auto-Sharding机制，可以自动实现集群的数据和负载均衡；
- 性能卓越。MongoDB对文档进行自动动态填充，预分配数据文件，用空间换取性能的稳定。默认的存储引擎中使用了内存映射文件，将内存的管理工作交给操作系统去处理。
- 管理简便。尽可能的让服务器自动配置，通过复制机制来提升系统的可靠性。
MongoDB的核心概念是文档，多个键及其相应的值有序地存放在一起组成文档，文档类似于关系型数据库中的元组。多个文档组成集合，集合如同关系型数据库中的表。多个集合组成数据库，一个MongoDB的实例可以承载多个数据库，每个数据库之间是完全独立的。
MongoDB的文档采用BSON格式存储，BSON是Binary JSON的简写，是一种类似于JSON文档的二进制序列化方案。
四丶图形数据库
图形数据库就是将数据存储在图（Graph）结构中。图示是一个简单的有向无环图。
其中，节点表示一个实体。例如人或商品。边表示点与点之间的连接关系，可以是有方向和无向的。如用户Ａ买了商品Ｂ表示Ａ→Ｂ；如果用户Ａ与用户Ｃ相互都认识，这种关系就是双向的，表示为 Ａ←→Ｃ。属性表示点和边所附带的属性。例如用户姓名、年龄等。需要注意的是每个点或边的属性是动态可变的。
图形数据库可以看作是结点与关系的集合，图形数据库就是将数据存储在拥有属性的结点中，并用关系将这些结点组织起来。
数据存储的重要目的是为了检索。图的查找与搜索可以通过遍历算法完成，根据算法，从开始结点到与之相连的结点查询诸如“我好友的好友是哪些人”等问题。所以通过遍历算法可以对图进行导航与操作，从而确定结点之间的路径。
适用的场景
1）在一些关系性强的数据中；
2）推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定。
不适用场景
不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图。