nosql分析

 

一、数据模型及操作模型

a)         Key存储

Key-Value存储

最简单的结构。

 

Key – 结构化数据 存储

Key对应结构化数据存储，其典型代表是Redis，Redis将Key-Value存储的Value变成了结构化的数据类型。Value的类型包括数字、字符串、列表、集合以及有序集合，可对复杂数据类型进行操作。

 

Key – 文档 存储

Key – 文档存储的代表有CouchDB、MongoDB和Riak。这种存储方式下Key-Value的Value是结构化的文档，通常这些文档是被转换成JSON或者类似于JSON的结构进行存储。

 

BigTable 的列簇式存储

HBase和Cassandra的数据模型都借鉴了Google 的BigTable。这种数据模型的特点是列式存储，每一行数据的各项被存储在不同的列中（这些列的集合称作列簇）。而每一列中每一个数据都包含一个时间戳属性，这样列中的同一个数据项的多个版本都能保存下来。

 

b)       图结构存储

Neo4j和HyperGraphDB是当前最流行的图结构数据库。

 

总特点：Schema-free的存储，动态增加属性。

 

二、横向扩展

横向扩展的目标是达到线性的效果，即如果增加一倍的机器，那么负载能力应该也能相应的增加一倍。其主要需要解决的问题是数据在多台机器间分布。主要通过数据分片和分区。

a)        分片策略

分片的意思是，没有任何一台机器可以处理所有读写请求。很多NoSQL系统都是基于键值模型的，基本不会有对整个数据进行查询的时候，因此分片通常也基于数据的键来做：键的一些属性会决定这个键值对存储在哪台机器上。

 

数据分片在Cassandra、HBase、Voldemort和Riak等都有实现，最近MongoDB和Redis也在做相应的实现。而有的并不提供内置的分片支持，比如CouchDB更加注重单机性能的提升。通常借助其它的技术在上层来进行负载分配。

 

i.     协调器进行数据分片

CouchDB专注于单机性能，于是出现了协调器Lounge 和 BigCouch，通过提供一个proxy层来对CouchDB中的数据进行分片。proxy作为CouchDB集群的前端机器，接受和分配请求。后端的CouchDB 之间并没有交互。协调器会将按操作的key值将请求分配到下层的具体某台机器。

Twitter 实现了一个叫Gizzard的协调器，可以实现数据分片和备份功能。Gizzard不关心数据类型，它使用树结构来存储数据范围标识。

ii.     一致性hash环算法

Hash算法要保证数据的均匀分布。比如Cassandra、Voldemort和Riak，基本上都使用了一致性hash算法。

 

hash环

一致性hash原理： hash函数H，可以通过数据的key值计算出一个hash值。我们将整个hash环的范围定义为［1，L］这个区间，将刚才算出的hash值对L进行取余，就能算出一个key值在这个环上的位置。而每一台真实服务器结点就会负责［1-L］之间的某个区间的数据。如上图，就是一个五个结点的hash环。

数据冗余容错：一般通过冗余保证节点的fail-over，hash环中一般顺序保存，例如冗余系数为3，那么A节点的数据会在ABC节点上保存。A节点出现故障， B，C节点就能处理这部分数据的请求。

解决数据不均：虚拟节点映射，例如将A节点映射为A_1，A_2, A_3, A_4，4个节点，使Hash分布更加均匀。

 

a)        连续范围分区策略

相对于按照单个的key进行的分片，连续范围分区就是对一段key进行分片。

 

类似一致性hash，连续范围分区会把key值按连续的范围分段，每段数据会保存在某个节点上，然后会被冗余备份到其它的节点，通过一份映射关系表，记录哪一段key值对应存在哪台机器上。和一致性hash不同的是，连续范围分区使得key值上相邻的两个数据在存储上也基本上是在同一个数据段。

 

BigTable的连续范围分区：

BigTable 将数据切分成tablet数据块。每个tablet保存一定数量的键值对。然后每个Tablet 服务器会存储多个tablet块，每个tablet大概100-200MB大。如果tablet的数据大小变化， master机器会动态地调整tablet，合并和分裂，以及在各个机器上的分布。

 master服务器会把 tablet 的归属关系存在元数据表里。元数据实际上也是被切分成tablet保存在tablet服务器中的。这样整个数据存储就被分成了如上图的三层模型。

 HBase，MongoDB， Twitter的Gizzard借鉴了BigTable的分层理论来实现范围分区策略。

MongoDB用几台配置机器组成集群来管理数据的分布。这几台机器保存着相同的配置信息，实际上同时扮演了master的路由角色及Chubby 的角色。

Cassandra 提供了一个有序的分区表。Cassandra也使用了一致性hash算法进行数据分配，不同的是，它不是按单条数据进行hash，而是对一段范围内的数据进行hash，也就是说20号数据和21号数据基本上会被分配在同一台机器节点上。

 

hash分区：

优点：对数据一次hash就能确定节点位置，可以通过虚拟节点解决数据分布不均。

缺点：范围查询需要在多台机器上进行。节点故障时可能造成相邻节点负载飙升。

 

连续范围分区：

连续优点：可以对数据进行顺序和范围查询。

缺点：每次查询需要查找配置信息里的映射表，找到相应的数据段。另外配置节点是个故障单点。

 

三、 故障处理

BigTable中，master机器是一个单点，系统只能容忍短时间的master故障。如果tablet 服务器故障，那么master可以把对其上tablet的所有请求分配到其它机器节点。

 

为了监测和处理节点故障，BigTable实现了Chubby的模块，Chubby是一个分布式的锁系统，用于管理集群成员及检测各成员是否存活。ZooKeeper是Chubby的一个开源实现，有很多基于 Hadoop 的项目都使用它来进行二级master和tablet节点的调度。

Gossip

类Dynamo 应用都采用了Dynamo文档中说到的一种古老的方法：Gossip。通过这个方法，节点间能够互相保持联系并能够检测到故障节点。其具体做法是，每隔一段时间（比如一秒），一个节点就会随便找一个曾经有过通信的节点与其交换一下其它节点的健康状态。

 

四、事务机制

NoSQL系统通常注重性能和扩展性，而非事务机制，对性能的考虑远在ACID的保证之上。通常NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操作，在实际执行的时候是会串行的执行，保证了每一个Key-Value对不会被破坏。

 

五、 一致性

分布式系统CAP理论，一致性，可用性和分区容错不可能全部达到，导致一般的NOSQL模型为最终一致性或者强一致性。例如HBASE通过底层的HDFS来保证数据强一致性，像Voldemort，Cassandra和Riak这些类Dynamo的系统，允许用户在强一致性和最终一致性之间自由选择。当然也有其他的选择，例如Yahoo的PNUTS中，采用的就是松散的一致性和弱可用性结合的方法。强一致性需要对数据进行同步，降低性能。

 

最终一致性：

1、数据版本控制与冲突

由于同一份数据在不同的节点可能存在不同值，对数据的版本控制和冲突监测就变得尤为重要。类Dynamo的系统通常都使用了一种叫vector clock（向量时钟）的同步机制

 

2、读时修复

在数据读取时，如果有R个节点返回了一致的数据，那么协调器就可以认为这个值是正确的并返回给客户端了。但是在总共返回的N个值中，如果协调器发现有的数据不是最新的。那么它可以通过读时修复机制来对这些节点进行处理。这种方式在Dynamo中有描述，在Voldemort 、Cassandra和Riak中都得到了实现。当协调器发现有的节点数据不是最新时，它会在数据不一致的节点间启动一个冲突解决过程。

 

 

附录

NOSQLFAN网站：http://blog.nosqlfan.com/newslist

NOSQL Notes博客：http://www.nosqlnotes.net/archives/category/精通架构

经典文章NOSQL漫谈：http://sebug.net/paper/databases/nosql/Nosql.html

这几个是搜到的比较好的网站和文章