Key-文档存储

　　Key-文档存储的代表有 CouchDB、MongoDB 和 Riak。这种存储结构下 Key-Value 的 Value 是结构化的文档，通常这些文档是被转换成 JSON 或者类似于 JSON 的结构进行存储。文档可以存储列表，键值对以及层次结构复杂的文档。

　　BigTable 的列簇式存储

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

　　列式存储可以这样理解：将行 ID、列簇号，列号以及时间戳一起，组成一个 Key，然后将 Value 按 Key 的顺序进行存储。Key 值的结构化使这种数据结构能够实现一些特别的功能，最常用的就是将一个数据的多个版本存成时间戳不同的几个值，这样就能方便地保存历史数据。这种结构也能 天然地进行高效的松散列数据（在很多行中并没有某列的数据）存储。当然，对于那些很少有某一行有 NULL 值的列，由于每一个数据必须包含列标识，这又会造成空间的浪费。

　　图结构存储

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

　　复杂查询

　　在 NoSQL 存储系统中，有很多比键值查找更复杂的操作。比如 MongoDB 可以在任意数据行上建立索引，可以使用 Javascript 语法设定复杂的查询条件。BigTable 型的系统通常支持对单独某一行的数据进行遍历，允许对单列的数据进行按特定条件的筛选。CouchDB 允许你创建同一份数据的多个视图，通过运行 MapReduce 任务来实现一些更为复杂的查询或者更新操作。很多 NoSQL 系统都支持与 Hadoop 或者其他 MapReduce 框架结合来进行一些大规模数据分析工作。

　　事务机制

　　与关系型数据库不同的是，NoSQL 系统通常注重性能和扩展性，而非事务机制。传统的 SQL 数据库的事务通常都是支持 ACID 的强事务机制。ACID 的支持使得应用者能够很清楚他们当前的数据状态。对很多 NoSQL 系统来说，对性能的考虑远在 ACID 的保证之上。通常 NoSQL 系统仅提供行级别的原子性保证，也就是说同时对同一个 Key 下的数据进行的两个操作，在实际执行时是会串行的，保证了每一个 Key-Value 对不会被破坏。

　　Schema-free 的存储

　　还有一个很多 NoSQL 的共同点，就是它通常并没有强制的数据结构约束。即使是在文档型存储或者列式存储上，也不会要求某一个数据列在每一行数据上都必须存在。

　　数据可靠性

　　最理想的状态是，数据库会把所有写操作立刻写到持久化存储的设备，同时复制多个副本到不同地理位置的不同节点上，以防止数据丢失。但这种对数据安全性的要求对性能是有影响的，所以不同的 NoSQL 系统在自身性能的考虑下，在数据安全上采取了不太一样的策略。

　　单机可靠性

　　单机可靠性理解起来非常简单，它的定义是写操作不会由于机器重启或者断电而丢失。通常单机可靠性的保证是通过把数据写到磁盘来完成的，而这通常会造成磁盘I/O成为整个系统的瓶颈。下面我们谈谈一些在单机可靠性的保证下提高性能的方法。

　　控制fsync的调用频率

　　Redis 提供了几种对 fsync 调用频率的控制方法。应用开发者可以配置 Redis 在每次更新操作后都执行一次 fsync，这样会比较安全，当然也就比较慢。Redis 也可以设置成N秒种调用一次 fsync，这样性能会更好一点。但这样的后果就是一旦出现故障，最多可能导致N秒内的数据丢失。而对一些可靠性要求不太高的场合（比如仅仅把 Redis 当 Cache 用的时候），应用开发者甚至可以直接关掉 fsync 的调用：让操作系统来决定什么时候需要把数据 flush 到磁盘（译者注：这只是 Redis append only file 的机制，Redis 是可以关闭 aof 日志的，另外，Redis 本身支持将内存中数据 dump 成 rdb 文件的机制，和上面说的不是一回事）。