【IT168 应用】数据海量集中的地方，无疑是互联网运营商(或称网络服务提供商，NSP)的数据中心了，所以这里往往是存储技术发展的最前沿。也正因为海量的数据存储与访问，使得传统存储架构已经无法满足需求了。例如，每秒几十万次的随机IOPS(每秒I/O操作次数)，每秒10GB的流量，如果采用传统高端存储，其成本将是高不可攀的。而且很多时候需要多台存储才可以满足，后期的扩展性以及扩容成本也都是难以承受的，NSP当然不愿意骑虎难下。

　　正因有如此强烈的业务驱动，导致各NSP逐步采用分布式系统来构建其底层文件系统及数据库。例如先驱谷歌的GFS+Bigtable，以及后续追随者Amazon的Dynamo、Facebook的Cassandra、Microsoft的Azure、Yahoo的PNUTS、淘宝的TFS+Tair等。这些系统都是动辄数百甚至数千个节点组成的分布式集群，上面跑的分布式数据库系统就属于NoSQL系统。

　　NoSQL全称是Not Only SQL，是一种不同于关系型数据库的数据库管理系统设计方式，经常要避免使用SQL的 join 指令。NOSQL 实作可分二个重点, 重视使用硬盘, 或尽可能地利用 RAM做为存储。本文将为您简要介绍NoSQL的应用环境及特点。

　　弱环境

　　NSP的集群系统都是使用廉价的定制化的PC机来搭建的，单个节点有各自的计算资源和存储资源，互不共享，也就是Share-Nothing。而且，单节点的可靠性不高，所以NSP分布式系统的硬件环境为一种“弱环境”，为了保证最终的可靠性，那么就必须在软件层面实现“强环境”，例如，将数据块保存三个副本在三台独立的机器上。

　　也许有人会问，为什么是三个副本而不是两个副本呢?因为如果只有两份副本的话，发生数据丢失的可能性依然很大。例如，一旦某个节点故障或者某个磁盘故障，此时对应的数据就处于危险边缘。对于一个1000节点的集群，每周大概有20块硬盘损坏，保存同一个数据的两份副本的两个硬盘同时失效的可能性也是有的。所以如果保留三份副本的话，危险程度会大大降低。

　　CAP理论

　　传统的关系型数据库已经无法在保证性能的前提下达到如此高的扩展性，因为传统关系型数据库是要保证强一致性的(例如用户A写入的数据，用户B立即就能看到等等)。所以，一致性、性能、扩展性，这三者是不能够同时兼顾的，只能任选其中两者，这便是著名的CAP理论。而NSP的某些对外业务所需要的就是超高性能和扩展性，那么只好适当牺牲一致性了。而且，就大部分互联网服务而言，数据短暂的不一致是可以接受的。例如DNS解析，更换主机之后可能并不能实时刷新到全网范围。

　　上文说过，数据块要保留三个副本，那么是当所有副本都同步写入对应节点之后再向客户端返回成功信息，还是只写一份就返回成功信息?后者肯定是有利于性能，但是却牺牲了一致性。设想一下，如果某份副本还没有更新到对应节点，就有另一个客户端从这个尚未被同步的节点发起对这份数据的读操作，那么这个客户端将读到过期的数据，这就发生了数据不一致。CAP理论是指Consistency、Availability以及Partition Tolerance，分别指数据访问时的一致性、可用性(请求总是可以被执行和返回，不超时，可视为性能)以及分区容忍性。前两者大家都理解，最后一个“分区容忍性”是指大规模集群一旦遇到网络或者其他类型故障导致整个集群被裂为多个孤岛，此时集群是否依然正常提供服务，这一点可以视为扩展性中的一个子需求。

　　NWR模型

　　有什么办法可以保证一致性呢?办法当然有，有一个著名的模型叫做NWR模型，可以在一致性与性能之间实现巧妙的均衡。N表示对应数据块要保存的副本数，W表示成功了写入几份就可以向客户端返回成功信息，R表示为了保证读操作的一致性，客户端必须从保存这份副本的N个节点中的几个节点同时读出数据。

　　假设N=3，W=1，也就是刚才那个场景。那么如果R=1，则不能保证一致性。如果是从已经写入新数据的副本中读取，那么就是一致的，但也有可能从还没有写入最新数据的另外两个保存副本的节点里读取，这就不一致了，也就是说不能保证每次都读取到最新数据。

　　同理，如果R=2，同样不能保证。但是R如果=3，那么就可以保证。读出的这3份数据，至少有一份是最新的，那么通过判断数据块的timestamp(时间戳)或者序号就可以判断这3份中哪一份(或哪几份)是最新的，从而丢弃剩余的不一致的副本。而如果W=2，也就是必须同步的写成功2个副本才返回成功信号，那么读的时候只要读出2份就能保证至少有一份是最新的了。所以，只要W+R>N，即可保证读一致性。