NoSQL介绍

什么是NoSQL

  NoSQL，泛指非关系型的数据库，NoSQL即Not-Only SQL，它能够做为关系型数据库的良好补充。随着互联网web2.0网站的兴起，非关系型的数据库如今成了一个极其热门的新领域，非关系数据库产品的发展很是迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了不少难以克服的问题，例如： 

一、High performance - 对数据库高并发读写的需求

  web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，因此基本上没法使用动态页面静态化技术，所以数据库并发负载很是高，每每要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，可是应付上万次SQL写数据请求，硬盘IO就已经没法承受了。其实对于普通的BBS网站，每每也存在对高并发写请求的需求，例如网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，所以这是一个至关广泛的需求。

二、Huge Storage - 对海量数据的高效率存储和访问的需求 

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

三、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求 

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

四、数据来源多，原始数据不容易结构化，有强schema约束的关系型数据库再也不合适 
五、对数据存储的要求有变化，以CAP理论为指导，大多数系统并不要求强一致性，而是对数据存储系统的Availability & Partition tolerance有更高要求

 

NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤为是大数据应用难题。

  

NOSQL数据库一般知足BASE约束： 
1）Basic Availability 基本可用
系统在外界看来彷佛总处于可用状态，这是经过多机水平扩展的集群部署方案实现的，只要多数节点正常就能保证系统基本的可用性，只有落在故障节点的用户请求才会感知到系统不可用。 
2）Soft-state 柔性一致状态
大多数NOSQL系统经过牺牲强一致性来保证可用性和分区容忍性，也即，一个节点写入新数据后，更新不会当即传播至集群其它节点，因此落在其它节点上的读请求可能会读到旧数据。 
3）Eventual consistency 最终一致
NOSQL系统对最终一致性一般是能够保证的。值得一提的是，Neo4j这个图数据库虽然也属NOSQL阵营，但它是能够保证ACID约束的。

从定义来看，与关系型数据库的ACID强约束相比，BASE约束要松散一些，但灵活性有优点，所以，知足前述数据特征的互联网系统愈来愈依赖NOSQL系统也就不足为奇了。固然，一些对数据有ACID要求的系统仍是应该首选关系型数据库。 
总之，数据特征决定了咱们在实际工程中应该使用何种存储系统。

 

NoSQL数据库的四大分类以下：

 

 

一、 键值(Key-Value)存储数据库　Key-Value Stores

KV型NOSQL系统起源于Amazon开发的Dynamo系统（Amazon AWS提供的DynamoDB就是这货），能够把它理解为一个分布式的hashmap，支持SEG/GET元操做。

一个完整的分布式KV系统会将KEY按策略尽可能均匀地散列在不一样的节点上。其中一致性哈希是比较优雅的散列策略，它能够保证当某个节点挂掉时，只有该节点的数据须要从新散列。做为对比，若采用取模哈希策略，则集群有节点不可用时，取模的分母N发生变化，会致使几乎全部的KEY都要从新散列，代价过高。

大多数KV NOSQL一般不会关心存入的value究竟是什么，在它看来，那只是一堆字节而已，因此开发者也没法经过value的某些属性来获取整个value。若是开发者有根据value的部分字段查找数据的需求，那应该考虑使用文档型NOSQL系统。

典型的KV型NOSQL系统：Memcached, Redis及DynamoDB, Tokyo Cabinet/Tyrant, Voldemort, Berkeley DB

典型应用： 内容缓存，主要用于处理大量数据的高访问负载。 

数据模型： 一系列键值对

优点： 快速查询

劣势： 存储的数据缺乏结构化

不适用场景：

1.取代经过键查询，而是经过值来查询。Key-Value数据库中根本没有经过值查询的途径

2.须要储存数据之间的关系。在Key-Value数据库中不能经过两个或以上的键来关联数据。

3.事务的支持。在Key-Value数据库中故障产生时不能够进行回滚。

 

二、 列存储数据库　Column Family Stores

列式NOSQL系统起源于Google的BigTable，其数据模型能够看做是一个每行列数可变的数据表，它能够细分为4种实现模式，以下图所示。 
 
其中，Super Colunm Family模型能够理解为maps of maps，例如能够把一个做者和他的专辑结构化地存成Super Colunm Family模式，以下图所示。 
 
与KV型或文档型的NOSQL系统相比，列式存储系统对数据模型的表达力更强。

典型的列式NOSQL系统：BigTable, Cassandra, HBase, Cassandra, Riak

典型应用：分布式的文件系统

数据模型：以列簇式存储，将同一列数据存在一块儿

优点：查找速度快，可扩展性强，更容易进行分布式扩展

劣势：功能相对局限

适用场景：1.日志 2.博客平台,咱们储存每一个信息到不一样的列族中。举个例子，标签能够储存在一个，类别能够在一个，而文章则在另外一个。

不适用场景：1.ACID事务 2.原型设计。在模型设计之初，咱们根本不可能去预测它的查询方式，而一旦查询方式改变，咱们就必须从新设计列族。

 

三、 文档型数据库　Document Stores

对于须要跟具备层次文档结构的数据打交道的开发者来讲，文档型NOSQL系统提供了最天然的存储模式，它支持读/写一些标准格式的文档数据（典型如XML, YAML和JSON，甚至支持2进制的BSON格式）。

在最简单的应用中，文档数据能够经过其ID进行读写操做，此时，能够将文档型NOSQL系统看做是K-V系统。

但文档型NOSQL系统更广泛的应用场合是根据文档的某个属性字段来获取整个文档。根据属性快速获取包含该属性的全部文档的操做是经过索引来实现的，也即文档数据在写入时，系统会对某些文档属性创建索引，从而支持高效地反查操做。而维护索引是有代价的，所以，文档型NOSQL数据库适用于读多写少的场合。

须要注意的是，对于单个文档的读写，文档型NOSQL系统能够保证原子操做，但批量写入的事物原子性目前还不能由系统保证，须要开发者在应用程序中显式处理。

此外，目前大多数文档型NOSQL系统须要用户来规划数据在集群多个实例间的sharding策略，所以，系统的水平扩展问题须要在选型时重点考虑，例如MongoDB早期版本的auto sharding在运维上就容易坑人，致使其一直被诟病。做为对比，主流的KV NOSQL系统和列式NOSQL系统在底层实现时就支持自动sharding，一般无需开发者花费很大精力来处理。

典型的文档型NOSQL系统：MongoDB和Apache CouchDB

典型应用：Web应用（与Key-Value相似，Value是结构化的）

数据模型： 一系列键值对

 优点：数据结构要求不严格

 劣势： 查询性能不高，并且缺少统一的查询语法

不适用场景：不支持事务

 

四、 图形(Graph)数据库　Graph Databases

上面介绍的KV系统、文档型系统及列式存储系统可被统一称为聚合存储系统（Aggregate Stores），它们的共同点是不适合处理具备耦合关系的数据，即它们不适合用于须要理解数据关联关系的复杂查询，而这正是图数据库的用武之地。

图数据库能够细分为底层存储引擎和处理引擎两部分。有些图数据库实现了native的、为存储和管理图数据作过特别优化的图存储引擎（例如Neo4j），而有些图数据库底层存储是外接系统。至于处理引擎，有些数据库实现了具有index-free adjacency特性的引擎（如Neo4j），而有些图数据库并未作到这一点。

图数据库在查找数据时并不会特别依赖索引（严格地说，只是在定位初始节点时会用到索引），由于对于图来讲，节点间的关系能够用有向边表达出来。基于图的查询会利用这种局部临接关系遍历图，而非根据全局索引对图中节点作遍历，所以，对于有关联关系的数据来讲，利用图进行查询的性能会很高。

图数据库在组织数据时，经常使用的数据模型包括：属性图（property graphs）、超图（hypergraphs）和三元组（triples)，其中属性图模型是图数据库组织数据时广泛采用的主流模型，Neo4j便是采用属性图模型来表达数据间的关联关系。

上述3种图数据模型间的详细区别涉及较多术语，限于篇幅，本文不赘述，感兴趣的话能够翻阅”Graph Database (2nd Edition)”一书的附录部分。

相关数据库：Neo4J、InfoGrid、Infinite Graph

典型应用：社交网络

数据模型：图结构

优点：利用图结构相关算法。

劣势：须要对整个图作计算才能得出结果，不容易作分布式的集群方案。

 

3. 参考资料

1. Wikipedia: NOSQL
2. Wikipedia: CAP theorem
3. Book: Graph Database (2nd Edition), Appendix A. NOSQL Overview
4. Wikipedia: Consistent Hashing
5. Neo4j Blog: Demining the “Join Bomb” with Graph Queries, 文中解释了index-free adjacency对图遍历的重要性

参考连接：

http://blog.csdn.net/slvher/article/details/50212923

http://blog.csdn.net/sinat_20827235/article/details/52403639