NoSQL应用概述
2012-05-10 16:09:21 
阿炯
NoSQL数据尝试着提供那些关系数据库所不能提供的功能，无论是为了存储简单的键值对(key-value)，更短的时间长度，高速缓存，还是保持数据的非结构化集合(比如collections)，这些都是在关系型数据库和SQL(Structured Query Language)中很难实现的。
从设计上，NoSQL 数据库和管理系统都是非关系型(也称非范式型)的，它们并非基于同一种模型(如关系型数据库的关系模型)，而是每种数据库依据其不同的功能目标，选择了不同的模型。NoSQL产品越来越火，NoSQL产品通常以其高性能，强扩展性和高容错性为大家所称道。它们有一系列的特征：
1、数据量和计算量都很大
We’re dealing with much more data. Although advances in storage capacity and CPU speed have allowed the databases to keep pace, we’re in a new era where size itself is an important part of the problem, and any significant database needs to be distributed.
由于我们需要处理的数据集越来越大，其存储量已经远远超过了单机的容量，数据处理的需求也远远超过了单机CPU的运算能力。所以我们需要分布式的解决方案。
2、应用需要快速响应
We require sub-second responses to queries. In the ’80s, most database queries could run overnight as batch jobs. That’s no longer acceptable. While some analytic functions can still run as overnight batch jobs, we’ve seen the web evolve from static files to complex database-backed sites, and that requires sub-second response times for most queries.
我们对数据提供速度的要求越来越高，在80年代，可能很多运算都需要跑一整晚。但是这种事情放在现在就变得不可接受了。对于复杂的统计分析我们可以忍受，但是对于网站应用来说，快速响应是必须的。
3、必须要稳定
We want applications to be up 24/7. Setting up redundant servers for static HTML files is easy, but a database replication in a complex database-backed application is another.
我们需要提供7×24的服务。如果你的网站只有一个静态页，那估计问题不大，只需要做好WebServer的容错性就行了。而如果你是一个背后有数据库，有缓存的动态网站，那你就必须做好数据层的容错及自动故障迁移。
4、更高的IO性能，更大的数据吞吐量
We’re seeing many applications in which the database has to soak up data as fast (or even much faster) than it processes queries: in a logging application, or a distributed sensor application, writes can be much more frequent than reads. Batch-oriented ETL (extract, transform, and load) hasn’t disappeared, and won’t, but capturing high-speed data flows is increasingly important.
很多应用场景需要数据层提供更高的写性能和数据吞吐。比如日志型应用，对写性能的要求可能非常高，当写性能成为瓶颈时，通常我们很难难过升级单机配置来解决。所以分布式的需求在这里变得也很重要。
5、结构化数据不符合互联网应用的特点
We’re frequently dealing with changing data or with unstructured data. The data we collect, and how we use it, grows over time in unpredictable ways. Unstructured data isn’t a particularly new feature of the data landscape, since unstructured data has always existed, but we’re increasingly unwilling to force a structure on data a priority.
我们对非结构化数据的存储和处理需求日增，在这个变化的世界，互联网领域的应用可能越来越难像软件开发一样，去预先写义各种数据结构。
6、需求的关注点已经改变
We’re willing to sacrifice our sacred cows. We know that consistency and isolation and other properties are very valuable, of course. But so are some other things, like latency and availability and not losing data even if our primary server goes down. The challenges of modern applications make us realize that sometimes we might need to weaken one of these constraints in order to achieve another.
我们的应用场景对一致性，隔离性以及其它一些事务特性的需求可能越来越低，相反的，我们对性能，对扩展性的需求可能越来越高。于是在新的需求下，我们必须做出抉择，放弃一些我们习惯了的优秀功能，去获取一些我们需要的新的特性。
NoSQL数据库管理系统的大致分类
基于键/值的 NoSQL 数据库管理系统
基于列 NoSQL 数据库管理系统
基于文档的 NoSQL 数据库管理系统
基于图形的 NoSQL 数据库管理系统
NoSQL数据库不同的类型和功能有许多具体实现：
键/值：如 Redis，MemcacheDB等。
列：如 Cassandra，HBase等。
文档：如 MongoDB，Couchbase等。
图形：如 OrientDB，Neo4J等。
基于键值
该类型的数据库通过关键字与值的映射来工作，有点类似字典，没有结构也没有关系。连接到数据库服务器(例如Redis)以后，应用程序陈述一个关键字如the_answer_to_life并提供也这对应的值如42，这个值随后可以通过提供的关键字以相同的方式搜索。
键值数据库通常用于快速的存储基本信息，有时是一些处理过的非基本的，例如CPU和内存密集的计算。它们的表现非常好，性能高，且通常易于扩展。
注意：在计算机领域，字典通常指特定类型的数据对象，它们由键值对数组构成。
一些流行的基于键/值的数据存储如下:
Redis:
内存中的键/值存储，附有可选的持久化功能。
Riak:
高度分布式的，自我复制(replicated)的键/值存储。
Memcached / MemcacheDB:
基于内存的分布式键/值存储。
使用场景
基于键/值的数据存储一些常见的使用场景有：
缓存:
快速缓存数据，以供将来——可能是频繁地——使用。
用作队列:
部分键/值存储(例如 Redis)支持list，set，queue等类型。
分布式信息 / 任务处理:
可以用来实现观察者/发布订阅(Pub/Sub)模式。
保存活跃状态信息:
需要维护一个状态的应用很适合使用键/值存储。
基于列
基于列的NoSQL数据库管理系统通过提升基于键值的简单本质来工作。
虽然在互联网中它们难于理解，但是这些数据库的工作机制相当的简单，通过创建一个或者多个键值对的集合来与记录相匹配。
不像传统的关系数据库定义了模式，基于列的NoSQL解决方案不需要预定义表结构就可以处理数据。每条记录有一列或者多列，这些列包含了信息，每个记录的每列都可能是不相同的。
基本上，基于列的NoSQL数据库就是个二维数组，每个键(即行/记录)都连接有一个或多个键/值对，这些管理系统允许非常巨大和非结构化的数据被保存和使用(例如有非常多信息的记录)。
这些数据库通常用在当必须存储大量信息记录，简单的键/值对不足以应对时。基于列实现的数据库管理系统，模式自由的模型，扩容性非常好。
基于列的数据存储非常强大，它们能够可靠地存储非常大规模的重要数据。尽管在数据的组成方面并不“灵活”，这类数据库仍然功能强大，性能良好。
一些流行的基于列的数据存储有:
Cassandra:
建立在 BigTable 和 DynamoDB 基础上的基于列的数据存储。
HBase:
为 Apache Hadoop 设计的数据存储，创意来自 BigTable。
使用场景
基于列的数据存储的一些流行用例:
保存非结构化和非易失性的信息:
如果需要长时间保存一个巨大的属性和值的集合，基于列的数据存储是非常方便的。
扩容:
基于列的数据存储天生是高度可扩容的。他们可以处理那些有可怕数量的信息。
基于文档
基于文档的 NoSQL 数据库系统，就像一波瞬间席卷了许多人的最新潮流。这类数据库系统工作原理与基于列的数据库类似；然而它们支持更深层的嵌套，能得到复杂的结构(例如，文档包含在一个文档里，而这个文档又包含在另一个文档里)。
文档克服了基于列的数据库中键/值嵌套只能有一级或两级的限制。基本上，无论多么复杂、无论什么形态的结构都能形成一个文档，而文档就可以用这类数据库系统来储存。
尽管它们有这样强大的特性，并且支持以独立的键来查询记录，基于文档的数据库系统相比其他系统仍然有自己的问题和不足之处。例如，检索记录中的一个值就需要牵扯出整个记录，update 也是如此，而这都会严重地影响性能。
基于文档的数据存储非常适于保存许多不相关的复杂信息，不同结构之间可以有高度的可变性。
流行的一些基于文档的数据存储:
Couchbase:
基于JSON, 兼容“内存缓冲”的基于文档的数据存储。
CouchDB:
一个冲破性的基于文档的数据存储。
MongoDB:
一个非常流行和功能很好的数据库。
使用场景
使用基于文档的数据存储的一些普遍情况:
嵌套的信息:
基于文档的数据存储允许很深的嵌套，和复杂的数据结构。
JavaScript友好性:
基于文档的数据存储的最具决定性的功能之一是他们与应用程序交互的方式：利用对JS友好的JSON。
基于图形
最后来看看 NoSQL 数据库系统中的奇葩——基于图形的系统。
基于图形的数据库系统模型表示数据的方式与上文提到的三种模型截然不同。他们使用树形的结构(也就是所说的“图形”)，包括结点和通过关系(relation)相互连接的边。
与数学类似，某些特定操作在这类模型上会格外简单。这要感谢树形结构能链接信息、将相关信息(例如相关联的人)分组的本质。
这类数据库通常应用于关系(connection)需要建立明确边界的场景。例如，当你注册随便一个社交网络时，你朋友与你的关系，和他们朋友的朋友与你的关系，使用基于图形的数据库系统来处理会简单很多。
基于图形的数据存储提供了一个非常独特的功能，是任何其他数据库管理系统无法相比的。
一些流行的基于图形的数据库如下:
OrientDB:
一个非常快速的基于图形和文档的混合 NoSQL 数据存储，使用 Java 编写，包含几种不同的操作模式。
Neo4J:
一个非范式的，基于图形的 Java 编写的数据存储，非常热门而强大。
使用场景
基于图形的数据库一些常见的使用情景如下：
处理复杂的关联信息:
如同在简介中说过的一样，图形数据库在处理复杂但相关联的信息方面极其高效而易用。例如两个实体和与它们不同层次间接连接的实体之间的关联。
建模和处理分类:
图形数据库尤擅牵涉到关系的各种情形。以关系的方式来建模数据、为各种数据分类，用这类数据库可以处理得很好。
这里提供一个Pdf文档，其中介绍对比了各种Nosql及hbase的主要方面。
nosql.with.hbase.and.hadoop.presentation.bejug
数据库场景比较
MySQL还是PostgreSQL?
1、如果你的应用对数据的完整性和严肃性要求不高，但是追求处理的高速度。例如论坛和社区，你应该使用MySQL。
2、如果你的应用是一个严肃的商业应用，对数据完整性要求很高，而且你希望对一些商业数据逻辑进行很好的封装，例如网上银行，你应该使用PostgreSQL。
3、你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。
MongoDB
1、MongoDB适用案例
1)事件记录
应用程序对事件记录各有需求。在企业级解决方案中，许多不同的应用程序都需要记录事件。文档数据库可以把所有这些不同类型的事件都存起来，并作为事件存储的”中心数据库”使用。如果事件捕获的数据类型一直在变，那么就更应该用文档数据库了。可以按照触发事件的应用程序名”分片”，也可以按照order_processed(表示订单已处理)或customer_logged(表示客户已记录)等事件类型”分片”。
2)内容管理系统及博客平台
由于文档数据没有”预设模式”，而且通常支持JSON文档，所以它们很适合在用”内容管理系统”及网站发布程序上，也可以用来管理用户评论、用户注册、用户配置和面向Web文档。
3)网站分析与实时分析
文档数据库可存储实时分析数据。由于可以只更新部分文档内容，所以用它来存储”页面浏览量”(page view)或”独立访问数”会非常方便，而且无需改变模式即可新增度量标准。分析：鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量。
4)电子商务应用程序
电子商务类应用程序通常需要采用较为灵活的模式，以存储产品和订单。同时，它们需要在不做高成本数据库重构及数据迁移的前提下进行其数据模型。
5)日志
企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以我们可以使用它储存不同的信息。
2、MongoDB不适用的场合
1)目前对于事务型业务、以及关联操作业务不适合。
2)在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务，如果对这方面有需求则不应该选择这个解决方案。
键值(Key-Value)数据库
键值数据库就像在传统语言中使用的哈希表。你可以通过key来添加、查询或者删除数据，鉴于使用主键访问，所以会获得不错的性能及扩展性。
1、键值(Key-Value)数据库适用的场景
储存用户信息，比如会话、配置文件、参数、购物车等等。这些信息一般都和ID(键)挂钩，这种情景下键值数据库是个很好的选择。
2、键值(Key-Value)数据库不适用场景
通过值来查询，而非通过键查询。Key-Value数据库中根本没有通过值查询的途径。
需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。
事务的支持。在Key-Value数据库中故障产生时不可以进行回滚。
Cassandra
1、Cassandra使用场景
1)事件记录
由于列族数据库可存放任意数据结构，所以它很适合用来保存应用程序状态或运行中遇到的错误等事件信息。在企业级环境下，所有应用程序都可以把事件写入Cassandra数据库。它们可以用appname:timestamp(应用程序名：时间戳)作为行键，并使用自己需要的列。由于Cassandra的写入能力可扩展，所以在事件记录系统中使用它效果会很好。
2)内容管理系统与博客平台
使用列族，可以把博文的”标签”(tag)、”类别”(category)、”链接”(link)和”trackback”(俗称引用告知，是一种网志工具，它可以让文章作者知道该文读者中有哪些人撰写了哪些与之有关的文章)等属性放在不同的列中。评论信息即可以与上述内容放在同一行，也可以移到另一个”键空间”。同理，博客用户与实际博文亦可存于不同列族中。博客平台：我们储存每个信息到不同的列族中。举个例子，标签、类别、文章分别储存在不同列族。
3)计数器
在网络应用程序中，通常要统计某页面的访问人数并对其分类，以算出分析数据。此时可使用ConterColumnType来创建列族。
创建好列族后，可以使用任意列记录网络应用程序中每个用户访问每一页面的次数。
也可以使用CQL增加计数器的值：
4)限期使用
我们可能需要向用户提供试用版，或是在网站上让某个广告条显示一定时间。这些功能可以通过”带过期时限的列”(expiring column)来完成。这种列过了给定时限后，就会又Cassandra自动删除。这个时限叫做TTL(Time To Live，生存时间)，以秒为单位。经过TTL指定的时长后，这种列就被删掉了。程序若检测到此列不存在，则可收回用户访问权限或移除广告条。
5)日志
因为我们可以将数据储存在不同的列中，每个应用程序可以将信息写入自己的列族中。
2、Cassandra不适合场合
有些问题用列族数据库来解决并不是最佳选择，比如说需要以”ACID事务”执行写入及读取操作的系统。如果想让数据库根据查询结果来聚合数据(例如sum求和)或avg(求平均值)，那么得把每一行数据都读到客户端，并在此执行操作。
在开发早期原型或开始试探某个技术方案时，不太适合用Cassandra。因为开发初期无法确定查询模式的变化情况，而查询模式一旦改变，列族的设计也要随之修改。这将阻碍产品创新团队的工作并降低开发者的生产能力。
在关系型数据库中，数据模式的修改成本很高，但是这却降低了查询模式的修改成本。Cassandra则与之相反，改变其查询模式要比改变数据模式代价更高。
简单说来：
如果我们需要ACID事务。Cassandra就不支持事务。
原型设计。如果我们分析Cassandra的数据结构，我们就会发现结构是基于我们期望的数据查询方式而定。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。
图数据库(Neo4j)
1、图数据库(Neo4j)适用案例
1)互联数据
部署并使用图数据库来处理社交网络非常高效。社交图里并不是只能有”朋友”这种关系，例如也可以用它们表示雇员、雇员的学识，以及这些雇员与其他雇员在不同项目中的工作位置。任何富含链接关系的领域都很适合用图数据库表示。
假如同一个数据库含有不同领域(像社交领域、空间领域、商务领域等)的领域实体，而这些实体之间又有关系，那么图数据库提供的跨领域遍历功能，可以让这些关系变得更有价值。
2)安排运输路线、分派货物和基于位置的服务
投递过程中的每个地点或地址都是一个节点，可以把送货员投递货物时所经全部节点建模为一张节点图。节点间关系可带有距离属性，以便高效投递货物。距离与位置属性也可用在名胜图(graph of places of interest)中，这样应用程序就可向用户推荐其附近的好餐馆及娱乐场所了。还可将书店、餐馆等售点(point of sales)做成节点，当用户靠近时，便可以通知他们，提供基于位置的服务。
3)推荐引擎
在系统中创建节点与关系时，可以利用它们为客户推荐信息。例如”您的朋友也买了这件产品”或”给这些货品开发票时，通常也要为哪些货品一并开票”。还可以用它们向旅行者提议“来巴塞罗那旅游的人一般都会去看看安东尼.高迪所设计的建筑”。
用图数据库推荐信息时，要注意他的一个副作用——随着数据量变多，推荐信息所用的节点及关系数也会激增。同一份数据可以挖掘出不同信息。例如，既可以从中看出客户总是将其与那些产品一并购买，也可以查出与此产品一并开发票的其余产品。若两者不匹配，则可发出警示。图数据库与其他”推荐引擎”一样，也可以根据关系间的模式侦测交易欺诈。如果我们将数据以图的形式表现，将会非常有益于推荐的制定。
2、图数据库Neo4j不适用场合
1)图数据库Neo4j对于更新全部或某子集内的实体就不适用。比如，在某个”数据分析解决方案”中，只要一个属性变了，全部实体都得更新。此时图数据库的效果就不理想了，因为没有哪个简单的操作能一次性改变所有节点中的某个属性。即便数据模型适合问题领域，某些图数据库可能也无法处理那么大的数据量，尤其在执行”全局图操作”时更是如此。
2)不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图。
从设计上，NoSQL 数据库和管理系统都是非关系型(也称非范式型)的，它们并非基于同一种模型(如关系型数据库的关系模型)，而是每种数据库依据其不同的功能目标，选择了不同的模型。NoSQL产品越来越火，NoSQL产品通常以其高性能，强扩展性和高容错性为大家所称道。它们有一系列的特征：
1、数据量和计算量都很大
We’re dealing with much more data. Although advances in storage capacity and CPU speed have allowed the databases to keep pace, we’re in a new era where size itself is an important part of the problem, and any significant database needs to be distributed.
由于我们需要处理的数据集越来越大，其存储量已经远远超过了单机的容量，数据处理的需求也远远超过了单机CPU的运算能力。所以我们需要分布式的解决方案。
2、应用需要快速响应
We require sub-second responses to queries. In the ’80s, most database queries could run overnight as batch jobs. That’s no longer acceptable. While some analytic functions can still run as overnight batch jobs, we’ve seen the web evolve from static files to complex database-backed sites, and that requires sub-second response times for most queries.
我们对数据提供速度的要求越来越高，在80年代，可能很多运算都需要跑一整晚。但是这种事情放在现在就变得不可接受了。对于复杂的统计分析我们可以忍受，但是对于网站应用来说，快速响应是必须的。
3、必须要稳定
We want applications to be up 24/7. Setting up redundant servers for static HTML files is easy, but a database replication in a complex database-backed application is another.
我们需要提供7×24的服务。如果你的网站只有一个静态页，那估计问题不大，只需要做好WebServer的容错性就行了。而如果你是一个背后有数据库，有缓存的动态网站，那你就必须做好数据层的容错及自动故障迁移。
4、更高的IO性能，更大的数据吞吐量
We’re seeing many applications in which the database has to soak up data as fast (or even much faster) than it processes queries: in a logging application, or a distributed sensor application, writes can be much more frequent than reads. Batch-oriented ETL (extract, transform, and load) hasn’t disappeared, and won’t, but capturing high-speed data flows is increasingly important.
很多应用场景需要数据层提供更高的写性能和数据吞吐。比如日志型应用，对写性能的要求可能非常高，当写性能成为瓶颈时，通常我们很难难过升级单机配置来解决。所以分布式的需求在这里变得也很重要。
5、结构化数据不符合互联网应用的特点
We’re frequently dealing with changing data or with unstructured data. The data we collect, and how we use it, grows over time in unpredictable ways. Unstructured data isn’t a particularly new feature of the data landscape, since unstructured data has always existed, but we’re increasingly unwilling to force a structure on data a priority.
我们对非结构化数据的存储和处理需求日增，在这个变化的世界，互联网领域的应用可能越来越难像软件开发一样，去预先写义各种数据结构。
6、需求的关注点已经改变
We’re willing to sacrifice our sacred cows. We know that consistency and isolation and other properties are very valuable, of course. But so are some other things, like latency and availability and not losing data even if our primary server goes down. The challenges of modern applications make us realize that sometimes we might need to weaken one of these constraints in order to achieve another.
我们的应用场景对一致性，隔离性以及其它一些事务特性的需求可能越来越低，相反的，我们对性能，对扩展性的需求可能越来越高。于是在新的需求下，我们必须做出抉择，放弃一些我们习惯了的优秀功能，去获取一些我们需要的新的特性。
NoSQL数据库管理系统的大致分类
基于键/值的 NoSQL 数据库管理系统
基于列 NoSQL 数据库管理系统
基于文档的 NoSQL 数据库管理系统
基于图形的 NoSQL 数据库管理系统
NoSQL数据库不同的类型和功能有许多具体实现：
键/值：如 Redis，MemcacheDB等。
列：如 Cassandra，HBase等。
文档：如 MongoDB，Couchbase等。
图形：如 OrientDB，Neo4J等。
基于键值
该类型的数据库通过关键字与值的映射来工作，有点类似字典，没有结构也没有关系。连接到数据库服务器(例如Redis)以后，应用程序陈述一个关键字如the_answer_to_life并提供也这对应的值如42，这个值随后可以通过提供的关键字以相同的方式搜索。
键值数据库通常用于快速的存储基本信息，有时是一些处理过的非基本的，例如CPU和内存密集的计算。它们的表现非常好，性能高，且通常易于扩展。
注意：在计算机领域，字典通常指特定类型的数据对象，它们由键值对数组构成。
一些流行的基于键/值的数据存储如下:
Redis:
内存中的键/值存储，附有可选的持久化功能。
Riak:
高度分布式的，自我复制(replicated)的键/值存储。
Memcached / MemcacheDB:
基于内存的分布式键/值存储。
使用场景
基于键/值的数据存储一些常见的使用场景有：
缓存:
快速缓存数据，以供将来——可能是频繁地——使用。
用作队列:
部分键/值存储(例如 Redis)支持list，set，queue等类型。
分布式信息 / 任务处理:
可以用来实现观察者/发布订阅(Pub/Sub)模式。
保存活跃状态信息:
需要维护一个状态的应用很适合使用键/值存储。
基于列
基于列的NoSQL数据库管理系统通过提升基于键值的简单本质来工作。
虽然在互联网中它们难于理解，但是这些数据库的工作机制相当的简单，通过创建一个或者多个键值对的集合来与记录相匹配。
不像传统的关系数据库定义了模式，基于列的NoSQL解决方案不需要预定义表结构就可以处理数据。每条记录有一列或者多列，这些列包含了信息，每个记录的每列都可能是不相同的。
基本上，基于列的NoSQL数据库就是个二维数组，每个键(即行/记录)都连接有一个或多个键/值对，这些管理系统允许非常巨大和非结构化的数据被保存和使用(例如有非常多信息的记录)。
这些数据库通常用在当必须存储大量信息记录，简单的键/值对不足以应对时。基于列实现的数据库管理系统，模式自由的模型，扩容性非常好。
基于列的数据存储非常强大，它们能够可靠地存储非常大规模的重要数据。尽管在数据的组成方面并不“灵活”，这类数据库仍然功能强大，性能良好。
一些流行的基于列的数据存储有:
Cassandra:
建立在 BigTable 和 DynamoDB 基础上的基于列的数据存储。
HBase:
为 Apache Hadoop 设计的数据存储，创意来自 BigTable。
使用场景
基于列的数据存储的一些流行用例:
保存非结构化和非易失性的信息:
如果需要长时间保存一个巨大的属性和值的集合，基于列的数据存储是非常方便的。
扩容:
基于列的数据存储天生是高度可扩容的。他们可以处理那些有可怕数量的信息。
基于文档
基于文档的 NoSQL 数据库系统，就像一波瞬间席卷了许多人的最新潮流。这类数据库系统工作原理与基于列的数据库类似；然而它们支持更深层的嵌套，能得到复杂的结构(例如，文档包含在一个文档里，而这个文档又包含在另一个文档里)。
文档克服了基于列的数据库中键/值嵌套只能有一级或两级的限制。基本上，无论多么复杂、无论什么形态的结构都能形成一个文档，而文档就可以用这类数据库系统来储存。
尽管它们有这样强大的特性，并且支持以独立的键来查询记录，基于文档的数据库系统相比其他系统仍然有自己的问题和不足之处。例如，检索记录中的一个值就需要牵扯出整个记录，update 也是如此，而这都会严重地影响性能。
基于文档的数据存储非常适于保存许多不相关的复杂信息，不同结构之间可以有高度的可变性。
流行的一些基于文档的数据存储:
Couchbase:
基于JSON, 兼容“内存缓冲”的基于文档的数据存储。
CouchDB:
一个冲破性的基于文档的数据存储。
MongoDB:
一个非常流行和功能很好的数据库。
使用场景
使用基于文档的数据存储的一些普遍情况:
嵌套的信息:
基于文档的数据存储允许很深的嵌套，和复杂的数据结构。
JavaScript友好性:
基于文档的数据存储的最具决定性的功能之一是他们与应用程序交互的方式：利用对JS友好的JSON。
基于图形
最后来看看 NoSQL 数据库系统中的奇葩——基于图形的系统。
基于图形的数据库系统模型表示数据的方式与上文提到的三种模型截然不同。他们使用树形的结构(也就是所说的“图形”)，包括结点和通过关系(relation)相互连接的边。
与数学类似，某些特定操作在这类模型上会格外简单。这要感谢树形结构能链接信息、将相关信息(例如相关联的人)分组的本质。
这类数据库通常应用于关系(connection)需要建立明确边界的场景。例如，当你注册随便一个社交网络时，你朋友与你的关系，和他们朋友的朋友与你的关系，使用基于图形的数据库系统来处理会简单很多。
基于图形的数据存储提供了一个非常独特的功能，是任何其他数据库管理系统无法相比的。
一些流行的基于图形的数据库如下:
OrientDB:
一个非常快速的基于图形和文档的混合 NoSQL 数据存储，使用 Java 编写，包含几种不同的操作模式。
Neo4J:
一个非范式的，基于图形的 Java 编写的数据存储，非常热门而强大。
使用场景
基于图形的数据库一些常见的使用情景如下：
处理复杂的关联信息:
如同在简介中说过的一样，图形数据库在处理复杂但相关联的信息方面极其高效而易用。例如两个实体和与它们不同层次间接连接的实体之间的关联。
建模和处理分类:
图形数据库尤擅牵涉到关系的各种情形。以关系的方式来建模数据、为各种数据分类，用这类数据库可以处理得很好。
这里提供一个Pdf文档，其中介绍对比了各种Nosql及hbase的主要方面。
nosql.with.hbase.and.hadoop.presentation.bejug
数据库场景比较
MySQL还是PostgreSQL?
1、如果你的应用对数据的完整性和严肃性要求不高，但是追求处理的高速度。例如论坛和社区，你应该使用MySQL。
2、如果你的应用是一个严肃的商业应用，对数据完整性要求很高，而且你希望对一些商业数据逻辑进行很好的封装，例如网上银行，你应该使用PostgreSQL。
3、你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。
MongoDB
1、MongoDB适用案例
1)事件记录
应用程序对事件记录各有需求。在企业级解决方案中，许多不同的应用程序都需要记录事件。文档数据库可以把所有这些不同类型的事件都存起来，并作为事件存储的”中心数据库”使用。如果事件捕获的数据类型一直在变，那么就更应该用文档数据库了。可以按照触发事件的应用程序名”分片”，也可以按照order_processed(表示订单已处理)或customer_logged(表示客户已记录)等事件类型”分片”。
2)内容管理系统及博客平台
由于文档数据没有”预设模式”，而且通常支持JSON文档，所以它们很适合在用”内容管理系统”及网站发布程序上，也可以用来管理用户评论、用户注册、用户配置和面向Web文档。
3)网站分析与实时分析
文档数据库可存储实时分析数据。由于可以只更新部分文档内容，所以用它来存储”页面浏览量”(page view)或”独立访问数”会非常方便，而且无需改变模式即可新增度量标准。分析：鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量。
4)电子商务应用程序
电子商务类应用程序通常需要采用较为灵活的模式，以存储产品和订单。同时，它们需要在不做高成本数据库重构及数据迁移的前提下进行其数据模型。
5)日志
企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以我们可以使用它储存不同的信息。
2、MongoDB不适用的场合
1)目前对于事务型业务、以及关联操作业务不适合。
2)在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务，如果对这方面有需求则不应该选择这个解决方案。
键值(Key-Value)数据库
键值数据库就像在传统语言中使用的哈希表。你可以通过key来添加、查询或者删除数据，鉴于使用主键访问，所以会获得不错的性能及扩展性。
1、键值(Key-Value)数据库适用的场景
储存用户信息，比如会话、配置文件、参数、购物车等等。这些信息一般都和ID(键)挂钩，这种情景下键值数据库是个很好的选择。
2、键值(Key-Value)数据库不适用场景
通过值来查询，而非通过键查询。Key-Value数据库中根本没有通过值查询的途径。
需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。
事务的支持。在Key-Value数据库中故障产生时不可以进行回滚。
Cassandra
1、Cassandra使用场景
1)事件记录
由于列族数据库可存放任意数据结构，所以它很适合用来保存应用程序状态或运行中遇到的错误等事件信息。在企业级环境下，所有应用程序都可以把事件写入Cassandra数据库。它们可以用appname:timestamp(应用程序名：时间戳)作为行键，并使用自己需要的列。由于Cassandra的写入能力可扩展，所以在事件记录系统中使用它效果会很好。
2)内容管理系统与博客平台
使用列族，可以把博文的”标签”(tag)、”类别”(category)、”链接”(link)和”trackback”(俗称引用告知，是一种网志工具，它可以让文章作者知道该文读者中有哪些人撰写了哪些与之有关的文章)等属性放在不同的列中。评论信息即可以与上述内容放在同一行，也可以移到另一个”键空间”。同理，博客用户与实际博文亦可存于不同列族中。博客平台：我们储存每个信息到不同的列族中。举个例子，标签、类别、文章分别储存在不同列族。
3)计数器
在网络应用程序中，通常要统计某页面的访问人数并对其分类，以算出分析数据。此时可使用ConterColumnType来创建列族。
创建好列族后，可以使用任意列记录网络应用程序中每个用户访问每一页面的次数。
也可以使用CQL增加计数器的值：
4)限期使用
我们可能需要向用户提供试用版，或是在网站上让某个广告条显示一定时间。这些功能可以通过”带过期时限的列”(expiring column)来完成。这种列过了给定时限后，就会又Cassandra自动删除。这个时限叫做TTL(Time To Live，生存时间)，以秒为单位。经过TTL指定的时长后，这种列就被删掉了。程序若检测到此列不存在，则可收回用户访问权限或移除广告条。
5)日志
因为我们可以将数据储存在不同的列中，每个应用程序可以将信息写入自己的列族中。
2、Cassandra不适合场合
有些问题用列族数据库来解决并不是最佳选择，比如说需要以”ACID事务”执行写入及读取操作的系统。如果想让数据库根据查询结果来聚合数据(例如sum求和)或avg(求平均值)，那么得把每一行数据都读到客户端，并在此执行操作。
在开发早期原型或开始试探某个技术方案时，不太适合用Cassandra。因为开发初期无法确定查询模式的变化情况，而查询模式一旦改变，列族的设计也要随之修改。这将阻碍产品创新团队的工作并降低开发者的生产能力。
在关系型数据库中，数据模式的修改成本很高，但是这却降低了查询模式的修改成本。Cassandra则与之相反，改变其查询模式要比改变数据模式代价更高。
简单说来：
如果我们需要ACID事务。Cassandra就不支持事务。
原型设计。如果我们分析Cassandra的数据结构，我们就会发现结构是基于我们期望的数据查询方式而定。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。
图数据库(Neo4j)
1、图数据库(Neo4j)适用案例
1)互联数据
部署并使用图数据库来处理社交网络非常高效。社交图里并不是只能有”朋友”这种关系，例如也可以用它们表示雇员、雇员的学识，以及这些雇员与其他雇员在不同项目中的工作位置。任何富含链接关系的领域都很适合用图数据库表示。
假如同一个数据库含有不同领域(像社交领域、空间领域、商务领域等)的领域实体，而这些实体之间又有关系，那么图数据库提供的跨领域遍历功能，可以让这些关系变得更有价值。
2)安排运输路线、分派货物和基于位置的服务
投递过程中的每个地点或地址都是一个节点，可以把送货员投递货物时所经全部节点建模为一张节点图。节点间关系可带有距离属性，以便高效投递货物。距离与位置属性也可用在名胜图(graph of places of interest)中，这样应用程序就可向用户推荐其附近的好餐馆及娱乐场所了。还可将书店、餐馆等售点(point of sales)做成节点，当用户靠近时，便可以通知他们，提供基于位置的服务。
3)推荐引擎
在系统中创建节点与关系时，可以利用它们为客户推荐信息。例如”您的朋友也买了这件产品”或”给这些货品开发票时，通常也要为哪些货品一并开票”。还可以用它们向旅行者提议“来巴塞罗那旅游的人一般都会去看看安东尼.高迪所设计的建筑”。
用图数据库推荐信息时，要注意他的一个副作用——随着数据量变多，推荐信息所用的节点及关系数也会激增。同一份数据可以挖掘出不同信息。例如，既可以从中看出客户总是将其与那些产品一并购买，也可以查出与此产品一并开发票的其余产品。若两者不匹配，则可发出警示。图数据库与其他”推荐引擎”一样，也可以根据关系间的模式侦测交易欺诈。如果我们将数据以图的形式表现，将会非常有益于推荐的制定。
2、图数据库Neo4j不适用场合
1)图数据库Neo4j对于更新全部或某子集内的实体就不适用。比如，在某个”数据分析解决方案”中，只要一个属性变了，全部实体都得更新。此时图数据库的效果就不理想了，因为没有哪个简单的操作能一次性改变所有节点中的某个属性。即便数据模型适合问题领域，某些图数据库可能也无法处理那么大的数据量，尤其在执行”全局图操作”时更是如此。
2)不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图。
该文章最后由 阿炯 于 2016-03-07 14:45:15 更新，目前是第 2 版。