什么是NoSQL
NoSQL，泛指非关系型的数据库，NoSQL即Not-Only SQL，它可以作为关系型数据库的良好补充。随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：
1、High performance - 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。
2、Huge Storage - 对海量数据的高效率存储和访问的需求
类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
4、数据来源多，原始数据不容易结构化，有强schema约束的关系型数据库不再合适
5、对数据存储的要求有变化，以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数据库的四大分类如下：
1、 键值(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数据库中故障产生时不可以进行回滚。
2、 列存储数据库 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.原型设计。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。
3、 文档型数据库 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是结构化的）
数据模型： 一系列键值对
优势：数据结构要求不严格
劣势： 查询性能不高，而且缺乏统一的查询语法
不适用场景：不支持事务
4、 图形(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. 参考资料
- Wikipedia: NOSQL
- Wikipedia: CAP theorem
- Book: Graph Database (2nd Edition), Appendix A. NOSQL Overview
- Wikipedia: Consistent Hashing
- 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