NoSQL生态系统——相似Bigtable列存储，或者Dynamo的key存储（kv存储如BDB，结构化存储如redis，文档存储如mongoDB）

摘自：http://www.ituring.com.cn/article/4002#

NoSQL系统的数据操做接口应该是非SQL类型的。但在NoSQL社区，NoSQL被赋予了更具备包容性的含义，其意为Not Only SQL，即NoSQL提供了一种与传统关系型数据库不太同样的存储模式，这为开发者提供了在关系型数据库以外的另外一种选择。

在关联型的数据模型中，在现实世界中的不一样类型的个体被存储在不一样的表里。好比有一个专门存员工的员工表，有一个专门存部门的部门表。简单的查询操做，好比查询符合某个条件的全部行（例：employeeid = 3, 或者 salary > $20000）。更复杂一些的任务会让数据库作一些额外的工做，好比跨表的联合查询（例：查出3号员的部门名称是什么）。一些复杂的查询，好比统计操做（例：算出全部员工的平均工资），甚至可能会致使全表扫描。

表结构的定义规定了表中每一行数据的存储内容。若是你的数据结构化并无那么强，或者对每一行数据的要求比较灵活，那可能关联型的数据模型就太过严格了。

NoSQL运动受到了不少相关研究论文的启示，这全部论文中，最核心的有两个。 Google的BigTable[CDG+06]提出了一种颇有趣的数据模型，它将各列数据进行排序存储。数据值按范围分布在多台机器，数据更新操做有严格的一致性保证。 Amazon的Dynamo[DHJ+07]使用的是另一种分布式模型。Dynamo的模型更简单，它将数据按key进行hash存储。其数据分片模型有比较强的容灾性，所以它实现的是相对松散的弱一致性：最终一致性。 接下来咱们会深刻介绍这些设计思想，而实际上在现实中这些思想常常是混搭使用的。好比像HBase及其它一些NoSQL系统他们在设计上更接受BigTable的模型，而像Voldemort 系统它就和Dynamo更像。同时还有像Cassandra这种两种特性都具有的实现（它的数据模型和BigTable相似，分片策略和一致性机制和Dynamo相似）。

NoSQL系统舍弃了一些SQL标准中的功能，取而代之的是一些简单灵活的功能。NoSQL 的构建思想就是尽可能简化数据操做，尽可能让操做的执行效率可预估。在不少NoSQL系统里，复杂的操做都是留给应用层来作的，这样的结果就是咱们对数据层进行的操做获得简化，让操做效率可预知。 NoSQL系统不只舍弃了不少关系数据库中的操做。它还可能不具有关系数据库如下的一些特性：好比一般银行系统中要求的事务保证，一致性保证以及数据可靠性的保证等。事务机制提供了在执行多个命令时的all-or-nothing保证。一致性保证了若是一个数据更新后，那么在其以后的操做中都能看到这个更新。可靠性保证若是一个数据被更新，它就会被写到持久化的存储设备上（好比说磁盘），而且保证在数据库崩溃后数据可恢复。 经过放宽对上述几点特性的要求，NoSQL系统能够为一些非银行类的业务提供以性能换稳定的策略。而同时，对这几点要求的放宽，又使得NoSQL系统可以轻松的实现分片策略，将远远超出单机容量的大量数据分布在多台机器上的。

数据库的数据模型指的是数据在数据库中的组织方式，数据库的操做模型指的是存取这些数据的方式。一般数据模型包括关系模型、键值模型以及各类图结构模型。操做语言可能包括SQL、键值查询及MapReduce等。

13.2.1 基于key值存储的NoSQL数据模型

Key-Value 存储

Key-Value存储能够说是最简单的NoSQL存储。每一个key值对应一个任意的数据值。对NoSQL 系统来讲，这个任意的数据值是什么，它并不关心。好比在员工信念数据库里，exployee:30 这个key对应的可能就是一段包含员工全部信息的二进制数据。这个二进制的格式多是Protocol Buffer、Thrift或者Avro都无所谓。 若是你使用上面说的Key-Value存储来保存你的结构化数据，那么你就得在应用层来处理具体的数据结构：单纯的Key-Value存储是不提供针对数据中特定的某个属性值来进行操做。一般它只提供像set、get和delete这样的操做。以Dynamo为原型的Voldemort数据库，就只提供了分布式的Key-Value存储功能。BDB 是一个提供Key-Value操做的持久化数据存储引擎。

Key - 结构化数据 存储

Key - 结构化数据存储，其典型表明是Redis，Redis将Key-Value存储的Value变成告终构化的数据类型。Value的类型包括数字、字符串、列表、集合以及有序集合。除了set/get/delete 操做觉得，Redis还提供了不少针对以上数据类型的特殊操做，好比针对数字能够执行增、减操做，对list能够执行 push/pop 操做，而这些对特定数据类型的特定操做并无对性能形成多大的影响。经过提供这种针对单个Value进行的特定类型的操做，Redis能够说实现了功能与性能的平衡。

Key - 文档 存储

Key - 文档存储的表明有CouchDB、MongoDB和Riak。这种存储方式下Key-Value的Value是结构化的文档，一般这些文档是被转换成JSON或者相似于JSON的结构进行存储。文档能够存储列表，键值对以及层次结构复杂的文档。 MongoDB 将Key按业务分到各个collection里，这样以collection做为命名空间，员工信息和部门信息的Key就被隔开了。CouchDB和Riak把类型跟踪这种事留给了开发者去完成。文档型存储的灵活性和复杂性是一把双刃剑：一方面，开发者能够任意组织文档的结构，另外一方面，应用层的查询需求会变得比较复杂。

BigTable 的列簇式存储

HBase和Cassandra的数据模型都借鉴自Google 的BigTable。这种数据模型的特色是列式存储，每一行数据的各项被存储在不一样的列中（这些列的集合称做列簇）。而每一列中每个数据都包含一个时间戳属性，这样列中的同一个数据项的多个版本都能保存下来。 列式存储能够理解成这样，将行ID、列簇号，列号以及时间戳一块儿，组成一个Key，而后将Value按Key的顺序进行存储。Key值的结构化使这种数据结构可以实现一些特别的功能。最经常使用的就是将一个数据的多个版本存成时间戳不一样的几个值，这样就能很方便的保存历史数据。这种结构也能自然地进行高效的松散列数据（在不少行中并无某列的数据）存储。固然，另外一方面，对于那些不多有某一行有NULL值的列，因为每个数据必须包含列标识，这又会形成空间的浪费。 这些NoSQL系统对BigTable数据模型的实现多少有些差异，这其中以Cassandra进行的变动最为显著。Cassandra引入了超级列（supercolumn）的概念，经过将列组织到相应的超级列中，能够在更高层级上进行数据的组织，索引等。这一作法也取代了locality groups的概念（这一律念的实现可让相关的几个行的数据存储在一块儿，以提升存取性能）。

13.2.2 图结构存储

图结构存储是NoSQL的另外一种存储实现。图结构存储的一个指导思想是：数据并不是对等的，关系型的存储或者键值对的存储，可能都不是最好的存储方式。图结构是计算机科学的基础结构之一，Neo4j和HyperGraphDB是当前最流行的图结构数据库。

 

未完待续！