概述
为什么要使用NoSQL
今天我们通过第三方平台（例如QQ、微信、百度、微博等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作已经次方级的增长。如果要对这些用户数据进行挖掘，那SQL数据库已经不适用这些应用了，NoSQL数据库的发展却能很好的处理这些大数据。
RDBMS vs NoSQL
RDBMS:
-
高度组织化结构化数据
-
结构化查询语言
-
数据和关系都存储仔单独的表中
-
数据操纵语言、数据定义语言
-
严格的一致性
-
基础事务
NoSQL：
-
代表着不仅仅是SQL
-
没有声明性查询语言
-
没有预定义的模式
-
键值对存储，列存储，文档存储，图形数据库
-
最终一致性，而非ACID属性
-
非结构化和不可预知的数据
-
CAP定理
-
高性能、高可用和可伸缩性
NoSQL发展简史
NoSQL一词最早出现于1998年，是Carlo Strozzi开发的一个轻量、开源、不提供SQL功能的关系数据库。
2009年，Last.fm的Johan Oskarsson发起了一次关于分布式开源数据库的讨论[2]，来自Rackspace的Eric Evans再次提出了NoSQL的概念，这时的NoSQL主要指非关系型、分布式、不提供ACID的数据库设计模式。
2009年在亚特兰大举行的"no:sql(east)"讨论会是一个里程碑，其口号是"select fun, profit from real_world where relational=false;"。因此，对NoSQL最普遍的解释是"非关联型的"，强调Key-Value Stores和文档数据库的优点，而不是单纯的反对RDBMS。
3V + 3高
大数据时代的3V：（描述问题）
-
海量（volume）
-
多样（variety）
-
实时（velocity）
大数据时代的3高：（对程序的要求）
-
高并发
-
高可拓
-
高性能
NoSQL四种类型
-
键值（Key-Value）数据库
-
键值数据库就像在传统语言中使用的哈希表，可以通过key来添加、查询、删除数据，鉴于使用主键访问，所以会获得不错的性能和扩展性。
-
产品：
-
Riak
-
Redis
-
Memcached
-
-
有谁在用：
-
Github
-
Twitter
-
Instagram
-
Youtube
-
-
适用场景：
-
储存用户的信息，比如会话、配置文件、参数、购物车等。这些信息一般都和id（键）挂钩，这种情境下键值数据库是个很好的选择。
-
-
不适用场景：
-
取代通过键查询，而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径
-
需要存储数据之间的关系，在Key-Value数据库中不能通过两个或以上的键来关联数据
-
事务的支持。在Key-Value数据库中故障产生时不可以进行回滚
-
-
-
面向文档（Document-Oriented）数据库
-
面向文档数据库会将数据以文档的形式存储。每个文档都是自包含的数据单元，是一系列数据项的集合。每个数据项都有一个名称和对应的值，值既可以是简单的数据类型，如字符串、数字和日期等，也可以是复杂的类型，如有序列表和关联对象。数据存储的最小单位是文档，同一个表中存储的文档属性可以是不同的，数据可以使用XML、JSON或者JSONB等多种形式存储。
-
产品：
-
MongoDB\CouchDB\RavenDB
-
-
使用场景：
-
日志。企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以我们可以使用它存储不同的信息。
-
分析。鉴于它的弱模式结构，不改变模式下就可以存储不同的度量方法及添加新的度量
-
-
不适用场景：
-
在不同的文档上添加事务，Document-Oriented数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案
-
-
-
列存储（Wide Colum Store/Colum-Family）数据库
-
列存储数据库将数据存储在列簇（column family）中，一个列簇存储经常被一起查询的相关数据。举个例子，如果我们有一个Person类，我们通常会一起查询他们的名字和年龄而不是薪资。这种情况下，姓名和年龄就会被放入一个列簇中，而薪资则在另一个列族中。
-
产品：
-
Cassandra\HBase
-
-
谁在使用：
-
Ebay
-
Instagram
-
NASA
-
Twitter
-
FaceBook
-
-
适用场景：
-
日志。因为我们可以将数据存储在不同的列中，每个应用程序可以将信息写入自己的列中
-
博客平台。我们存储每个信息到不同的列族中。举个例子，标签可以存储在一个，类别可以在一个，而文章则在另一个
-
-
不适用场景：
-
如果我们需要ACID事务，Cassandra就不支持事务
-
原型设计。如果我们分析Cassandra的数据结构，我们就会发现结构是基于我们期望的数据查询方式而定的。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列簇。
-
-
-
图（graph-Oriented）数据库
-
图数据库允许我们将数据以图的方式存储，实体会被作为顶点，而实体之间的关系则会被作为边。比如我们有三个实体，雷军、金山和小米，则会有两个“founded by”的边将金山和小米连接到雷军。
-
产品：
-
Neo4j
-
infinite graph
-
orientDB
-
-
谁在使用：
-
Adobe
-
Cisco
-
t-mobile
-
-
适用场景：
-
在一些关系型强的数据中
-
推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的定制
-
-
不适用场景：
-
-