NoSQL的复兴和模型简化的力量（下篇）
混合引擎
还有一部分的存储引擎选择了多种引擎混合，比如最著名的应该是WiredTiger，大概是去年被 MongoDB 收购，现在成为了 MongoDB 的默认存储引擎。WiredTiger 内部有 LSM-Tree 和 B-tree 两种实现提供一套接口，根据业务的情况可自由选择。另外一些特殊数据结构的存储引擎在某些特殊场合下非常抢眼，比如极高压缩比TokuDB，采用了名为分形树的数据结构，在维持一个可接受的读写压力的情况下，能拥有 10 倍以上的压缩率。
NoSQL
说完了几个比较著名的存储引擎，我们来讲讲比较著名的 NoSQL。在我的定义中，NoSQL 是Not Only SQL 的缩写，所以可能包含的范围有内存数据库，持久化数据库等。总之就是和单机的关系型数据库不一样的结构化数据存储系统。
我们先从缓存开始。
memcached
前面提到了 memcached 应该是第一个大规模在业界使用的缓存数据库，memcached 的实现极其简单，相当于将内存用作大的 HASH Table，只能在上面 get/set/ 计数器等操作，在此之上用 libevent 封装了一层网络层和文本协议(也有简单的二进制协议)，虽然支持一些 CAS 的操作，但是总体上来看，还是非常简单的。
但是 memcached 的内存利用率并不太高，这个因为 memcached 为了避免频繁申请内存导致的内存碎片的问题，采用了自己实现的slab allocator 的方式。即内存的分配都是一块一块的，最终存储在固定长度的chunk 上，内存最小的分配单元是chunk，另外 libevent 的性能也并没有优化到极致，但是不妨碍 memcached 成为当时的开源缓存事实标准(另外，八卦一下，memcached 的作者Brad Fitzpatrick，现在在 Google，大家如果用 Golang 的话，Go 的官方 HTTP 包就是这哥们写的，是个很高产的工程师)。
Redis
如果我没记错的话，在 2009 年前后，一位意大利的工程师Antirez，开源了Redis。从此彻底颠覆了缓存的市场，到现在大多数缓存的业务都已用上Redis，memcached 基本退出了历史舞台。Redis 最大的特点是拥有丰富的数据结构支持，不仅仅是简单的 Key-Value，包括队列、集合、Sorted Set 等等，提供了非常丰富的表达力，而且 Redis 还提供 sub/pub 等超出数据库范畴的便捷功能，使得几乎一夜之间大家纷纷投入 Redis 的怀抱。
Twemproxy
但是随着 Redis 渐渐的普及，而且越用越狠，另外内存也越来越便宜，人们开始寻求扩展单机Redis的方案，最早的尝试是twitter 开源的twemproxy，twemproxy 是一个 Redis 中间件，基本只有最简单的数据路由功能，并没有动态的伸缩能力，但是还是受到了很多公司的追捧，因为确实没方案。随后的 Redis Cluster 也是难产了好久，时隔好几年，中间出了 7 个RC 版本，最后才发布;
2014 年底，我们开源了Codis，解决了 Redis 中间件的数据弹性伸缩问题，目前广泛应用于国内各大互联网公司中，这个在网上也有很多文章介绍，我也就不展开了。所以在缓存上面，开源社区现在倒是非常统一，就是 Redis 极其周边的扩展方案。
在 NoSQL 的大家庭中，MongoDB其实是一个异类，大多 NoSQL 舍弃掉 SQL 是为了追求更极致的性能和可扩展能力，而 MongoDB 主动选择了文档作为对外的接口，非常像 JSON 的格式。Schema-less 的特性对于很多轻量级业务和快速变更了互联网业务意义很大，而且 MongoDB 的易用性很好，基本做到了开箱即用，开发者不需要费心研究数据的表结构，只需要往里存就好了，这确实笼络了一大批开发者。
尽管 MongoDB 早期的版本各种不稳定，性能也不太好(早期的 Mongo 并没有存储引擎，直接使用了 mmap 文件)，集群模式还全是问题(比如至今还未解决的 Cluster 同步带宽占用过多的问题)，但是因为确实太方便了，在早期的项目快速迭代中，Mongo 是一个不错的选择。
但是这也正是它的问题，我不止一次听到当项目变得庞大或者「严肃」的时候，团队最后还是回归了关系型数据库。Anyway，在 2014 年底 MongoDB 收购了 WiredTiger 后，在 2.8 版本中正式亮相，同时 3.0 版本后更是作为默认存储引擎提供，性能和稳定性有了非常大的提升。
但是，从另一方面讲，Schema-less 到底对软件工程是好事还是坏事这个问题还是有待商榷。我个人是站在 Schema 这边的，不过在一些小项目或者需要快速开发的项目中使用 Mongo 确实能提升很多的开发效率，这是毋庸置疑的。
HBase
说到 NoSQL 不得不提的是HBase，HBase 作为Hadoop 旗下的重要产品，Google Bigtable的正统开源实现，是不是有一种钦定的感觉:)。提到 HBase 就不得不提一下Bigtable，Bigtable是Google内部广泛使用的分布式数据库，接口也不是简单的Key-Value，按照论文的说法叫：multi-dimensional sorted map，也就是 Value 是按照列划分的。Bigtable 构建在 GFS 之上，弥补了分布式文件系统对于海量、小的、结构化数据的插入、更新、随机读请求的缺陷。
HBase 就是这么一个系统的实现，底层依赖 HDFS。HBase 本身并不实际存储数据，持久化的日志和 SST file (HBase 也是 LSM-Tree 的结构) 直接存储在 HDFS 上，Region Server (RS) 维护了 MemTable 以提供快速的查询，写入都是写日志，后台进行 Compact，避免了直接随机读写 HDFS。
数据通过 Region 在逻辑上进行分割，负载均衡通过调节各个 Region Server 负责的 Region 区间实现。当某 Region 太大时，这个 Region 会分裂，后续可能由不同的 RS 负责，但是前面提到了，HBase 本身并不存储数据，这里的 Region 仅是逻辑上的，数据还是以文件的形式存储在 HDFS 上，所以 HBase 并不关心 Replication 、水平扩展和数据的分布，统统交给 HDFS 解决。
和 Bigtable 一样，HBase 提供行级的一致性，严格来说在CAP理论中它是一个 CP 的系统，但遗憾的是并没有更进一步提供 ACID 的跨行事务。HBase 的好处就不用说了，显而易见，通过扩展 RS 可以几乎线性提升系统的吞吐，及 HDFS 本身就具有的水平扩展能力。
但是缺点仍然是有的。
首先，Hadoop 的软件栈是 Java，JVM 的 GC Tuning 是一个非常烦人的事情，即使已经调得很好了，平均延迟也得几十毫秒;
另外在架构设计上，HBase 本身并不存储数据，所以可能造成客户端请求的 RS 并不知道数据到底存在哪台 HDFS DataNode 上，凭空多了一次 RPC;
第三，HBase 和 Bigtable 一样，并不支持跨行事务，在 Google 内部不停的有团队基于 Bigtable 来做分布式事务的支持，比如 MegaStore、Percolator。后来Jeff Dean有次接受采访也提到非常后悔没有在 Bigtable 中加入跨行事务，不过还好这个遗憾在 Spanner 中得到了弥补，这个一会儿说。
总体来说，HBase 还是一个非常健壮且久经考验的系统，但是需要你有对于 Java 和 Hadoop 比较深入的了解后，才能玩转，这也是 Hadoop 生态的一个问题，易用性真是不是太好，而且社区演进速度相对缓慢，也是因为历史包袱过重的缘故吧。
Cassandra
提到 Cassandra (C*)，虽然也是 Dynamo 的开源实现，但就没有这种钦定的感觉了。C* 确实命途多舛，最早 2008 由 Facebook 开发并开源，早期的 C* 几乎全是 bug，Facebook 后来索性也不再维护转过头搞 HBase 去了，一个烂摊子直接丢给社区。还好DataStax把这个项目捡起来商业化，搞了两年，终于渐渐开始流行起来。
C* 不能简单的归纳为读快写慢，或者读慢写快，因为采用了 qourm 的模型，调整复制的副本数以及读的数量，可以达到不同的效果，对于一致性不是特别高的场景，可以选择只从一个节点读取数据，达到最高的读性能。另外 C* 并不依赖分布式文件系统，数据直接存储在磁盘上，各个存储节点之间自己维护复制关系，减少了一层 RPC 调用，延迟上对比 HBase 还是有一定优势的。
不过即使使用 qourm 的模型也并不代表 C* 是一个强一致的系统。C* 并不帮你解决冲突，即使你 W(写的副本数) + R(读请求的副本数) > N(节点总数)，C* 也没办法帮你决定哪些副本拥有更新的版本，因为每个数据的版本是一个 NTP 的时间戳或者客户端自行提供，每台机器可能都有误差，所以有可能并不准确，这也就是为什么 C* 是一个 AP 的系统。不过 C* 一个比较友好的地方是提供了 CQL，一个简单的 SQL 方言，比起 HBase 在易用性上有明显优势。
即使作为一个 AP 系统，C* 已经挺快了，但是人们追求更高性能的脚步还是不会停止。应该是今年年初，ScyllaDB的发布就是典型的证明，ScyllaDB 是一个兼容 C* 的 NoSQL 数据库，不一样的是，ScyllaDB 完全用 C++ 开发，同时使用了类似 DPDK 这样的黑科技，具体我就不展开了，有兴趣可以到 Scylla 的官网去看看。BTW，国内的蘑菇街第一时间使用了 ScyllaDB，同时在 Scylla 的官网上 share 了他们的方案，性能还是很不错的。
