转载请注明出处： jiq?钦‘s technical Blog - 季义钦
一、开篇
淘宝之前使用的存储层架构一直是MySQL数据库，配合以MongDB，Tair等存储。
MySQL由于开源，并且生态系统良好，本身拥有分库分表等多种解决方案，因此很长一段时间内都满足淘宝大量业务的需求。但是由于业务的多样化发展，有越来越多的业务系统的需求开始发生了变化。一般来说有以下几类变化：
(1) 数据量变得越来越多，事实上现在淘宝几乎任何一个与用户相关的在线业务的数据量都在亿级别，每日系统调用次数从亿到百亿都有，且历史数据不能轻易删除。这需要有一个海量分布式文件系统，能对TB级甚至PB级别的数据提供在线服务。
(2) 数据量的增长很快且不一定能准确预计，大多数应用系统从上线起在一段时间内数据量都呈很快的上升趋势，因此从成本的角度考虑对系统水平扩展能力有比较强烈的需求，且不希望存在单点制约。
(3) 只需要简单的kv读取，没有复杂的join等需求。
(4) 对系统的并发能力以及吞吐量、响应延时有非常高的需求，并希望系统能保持强一致性。
(5) 通常系统的写入非常频繁，尤其是大量系统依赖于实时的日志分析。
(6) 希望能够快速读取批量数据（HBase基于行健存储的优势）。
(7) schema灵活多变，可能经常更新列属性或新增列。
(8) 希望能够方便使用，有良好且语义清晰的java接口。
以上需求综合在一起，我们认为hbase是一种比较适合的选择。
1、首先它的数据由hdfs天然地做了数据冗余，云梯三年的稳定运行，数据100%可靠己经证明了hdfs集群的安全性，以及服务于海量数据的能力。
2、其次hbase本身的数据读写服务没有单点的限制，服务能力可以随服务器的增长而线性增长，达到几十上百台的规模。
3、LSM-Tree模式的设计让hbase的写入性能非常良好，单次写入通常在1-3ms内即可响应完成，且性能不随数据量的增长而下降。
4、region（相当于数据库的分表）可以ms级动态的切分和移动，保证了负载均衡性。
5、由于hbase上的数据模型是按rowkey排序存储的，而读取时会一次读取连续的整块数据做为cache，因此良好的rowkey设计可以让批量读取变得十分容易，甚至只需要１次IO就能获取几十上百条用户想要的数据。
6、最后，淘宝大部分工程师是java背景的同学，因此hbase的api对于他们来说非常容易上手，培训成本相对较低。
这个问题足以说明，Hbase相对于MongDB拥有上面讲到的那几点优势。
另外FaceBook是Hbase目前的最大的用户，其抛弃了自创的最终一致性数据库Cassandra而选择了Hbase。http://wiki.apache.org/hadoop/Hbase/PoweredBy页面也罗列出了很多当前正在使用HBase的大用户。
二、NoSQL数据库特点
1、 MongDB特点：
(1) MongDB是文档存储，文档按组又分成集合。集合类似于关系数据库中的表，不过不同
的是其不对Schema进行严格约束，即一个集合可以包含任何文档。
文档以BSON格式存在，这是一种JSON类文档的二进制编码格式，结构类似于嵌套的键值对，每个文档都有一个唯一的标识。
(2) MongDB选择用内存映射文件存储，所以可以通过提供更大的RAM或者分配更大的虚拟内存可以提升MongDB的性能，可以看出高性能是贯穿MongDB设计的一个重要理念。
(3) 限制：因为采用内存映射文件存储，所以32位系统上数据库的最大值不能超过2G。此外单个文档不能超过16M，说明不适合存储大对象。还有一个MongDB数据库最多只能存储8000个集合。这些约束都限制了MongDB数据库的无限增长。
(4) 原子性：MongDB并不注重原子性，也没有定义并发操作中事物完整性和隔离级别，因此在更新同一个集合时，两个进程可能相互冲突。只有一类成为Modifier Operation的操作(主要有累加字段、设定字段值、删除字段等操作)才提供原子性。而Hbase和Hypertable等列式数据库提供行级的原子更新和一致性状态。
(5) 水平拓展：选用MongDB一个常见的原因是弱Schema集合，还有一个原因就是其良好的性能和可拓展性，最近的版本中MongDB开始支持自动分片，其支持将集合分开保存到多台机器上，每台机器保存一部分，即一个分片，故障转移通过复制分片来实现，这使得水平拓展变得容易了许多。
(6) 支持非常丰富的查询、支持各种索引、支持各种聚合函数、支持排序，总之拓展了关系型数据库的许多有用的功能。
(7) 和Mapreduce结合不是很好、当数据规模增大时，稳定性不够好。
虽然MongDB是一种NoSQL数据库，但是由于本身的一些特性和实际行业中的使用经验表明，MongDB更像是介于NoSQL数据库和内存数据库之间的一种数据库。
2、 Hbase特点：
Facebook是Hbase的最大用户，下面是我从SIGMOD2011上facebook发表的一篇论文翻译而来，详细说明了他们为什么选择Hbase。
Facebook主要给出了三类应用场景：Facebook Messaging、Facebook Insight 和 FacebookMetrics System(ODS)。Messaging 就是 Facebook 的新型消息服务，每个月存储1350亿条消息。Insight 是提供给开发者和网站拥有者的数据分析工具，可以帮助他们清楚了解到访问者如何与他们网站交互，以便更好地优化他们的服务。ODS 则是 Facebook 内部的软硬件状态统计系统，对于每一个或者一组服务器，都可以有效地从不同的维度来监控他们的状态。这三个应用场景都有各自的特色，但简单地来说，面临的问题是同样的：单机或者拆分的关系型数据库无法满足需求。
Facebook选择Hadoop/Hbase的主要原因有以下几点：
1、可拓展性：可以以最小的代价、无须停机的方式增加存储系统的容量。一些情况下我们需要快速增加系统的容量，并且能够自动负载、利用到这些新的硬件设备。
2、高写入吞吐量：大多数应用都需要存储巨大量的数据，这就要求很高的写入吞吐量。
3、单个data center内高性能、低延迟的强一致性：一些重要的应用、比如消息、要求很强的单个数据中心内的一致性，这些需求很直观来自于用户需求，比如展示在主页的“未读消息”的数目和inbox页面显示的消息就应当是高度一致的。尽管全局强一致性的分布式系统几乎是不可能的，但是一个系统至少能够提供在单个数据中心内的强一致性，这能够带来很好的用户体验。
4、高效的随机读取性能：尽管应用层的缓存技术(不管是嵌入式的还是memcached方式)被广泛应用，但是很多访问仍然没办法命中缓存，需要后端的存储系统来处理，Hbase随机读取性能很稳定。MySQL在随机读取方面非常优秀，但如果Hbase结合分布式缓存MemeCached或者MemBase，那么其读取性能就可以和MySQL比肩了。
5、高可用性以及灾难恢复：我们需要提供给用户高度可用的服务，不管是遇到计划中的事件（比如软件升级、或者硬件/容量的增加），还是遇到一些计划之外的事件（比如硬件失效）。我们也需要能够容许数据中心的一些数据丢失，能够在合理的时间范围内切换到其他数据中心来为用户提供服务。
6、故障隔离：我们在大量的MySQL数据库上的应用经验表明，故障隔离是非常关键的。单个数据库可以down掉，但是仅只有很小一部分用户会被这样的事件影响。类似地，在我们的Hadoop存储中，单个磁盘故障仅只会影响到一小部分数据，而且系统可以很快恢复。
7、原子的“读-修改-写”原语：原子的计数器和检查并设置(checkand set、或者称compare and swap)等API在构建无锁的并发应用时非常有用，可以帮助用户有效地解决多线程竞争造成的很多问题。
8、范围扫描：一些应用要求特定范围内的行的集合的高效检索。例如，给定用户的最近100条消息的检索。
FaceBook对HDFS做了一些优化：
HDFS最初是被设计为支持一些离线Mapreduce应用的批处理文件系统，在可拓展性和批量数据处理方面很优秀，基于一些实时性的需求，faceBook对HDFS进行了优化，目的是为了将其打造为更加通用的、低延迟的文件系统。主要优化包括：
(1) 将单节点的NameNode改为双节点的热备份。不过Facebook认为这个不是很重要，他们的HDFS集群四年来NameNode只出过一次问题，还是因为什么交易日志存储在错误的地方。
(2) RPC的优化。
FaceBook对Hbase也做了一些优化：
(1) 行级原子性、系统可用性的优化。个人看了一下，只能佩服faceBook。
(2) 性能优化主要从两点进行，一个是 compaction 性能，另一个是读性能。
读过 BigTable 论文的应该对其 memtable 和 compaction 的特性比较熟悉。这里主要讨论了让 minor compaction 也删除数据的好处，以及如何做 major compaction 能够提高合并的性能。在数据读性能方面，文章里主要讨论了减少 IO 操作的方法，其中包括 bloom filter和特定类型 meta 信息（时间戳）的使用。还有很重要的一点，在部署上保持 RegionServer 和物理文件的局部性！
Hbase主要适用场景：
1 大数据量 （100s TB级数据） 且有快速随机访问的需求。
例如淘宝的交易历史记录。数据量巨大无容置疑，面向普通用户的请求必然要即时响应。
2 容量的优雅扩展
大数据的驱使，动态扩展系统容量的必须的。例如：webPage DB。
3 业务场景简单，不需要关系数据库中很多特性（例如交叉列、交叉表，事务，连接等等）
4 优化方面：合理设计rowkey。因为hbase的查询用rowkey是最高效的，也几乎的唯一生产环境可行的方式。所以把你的查询请求转换为查询rowkey的请求吧。
HBase在淘宝的应用
个人感觉是最精华的部分，HBase在淘宝里用在三个地方：
a） 实时推荐、实时报表、实时计费
这类应用的特点是大量数据的实时写入以及读取
b） 大数据量类型项目
比如历史类或需要长期保存的数据
c） 二次分析类型项目
Hadoop集群做粗粒度分析，在线做二次分析，比如数据魔方。
三、NoSQL数据库对比
1、 可拓展性
虽然所有NoSQL数据库都承诺可拓展性，但是面对挑战是水平却不尽相同。
BigTable的相似产品Hbase和Hypertable暂时处于领先地位，内存存储(Membase或Redis)和文档数据库(MongDB或CouchBase)紧随其后，他们之间的差异随着数据量的增大而被无限放大，特别是到了PB级以后。
拓展性方面Hbase具备天生的优势，支持自动负载均衡，故障转移，压缩和单服务器多分片，而且Hbase和HDFS配合的非常好，HDFS能够通过复制和自动平衡轻松容纳跨越多个服务器的大文件。
所以所如果需要极端拓展性的话，列族NoSQL是最好的选择。
但是话又说回来，如果你的大量数据会以惊人的快节奏出现，例如一些实时的交易数据或者广告点击追踪数据，那么单靠列式存储无法提供完美的解决方案。这个时候你需要一些更加轻快、既支持快速读写、又支持实时处理的存储，没有什么比在内存里面处理数据更快了，所以你可以在Hbase前面搭配上MongDB/Redis来进行实时数据处理以及实时的数据挖掘等。其他一些实时性不是非常高的批量查询和数据挖掘可以利用Mapreduce在Hbase上进行。
2、 事务完整性和一致性
Hbase和Hypertable提供行级的原子更新以及一致性状态，MongDB提供文档级别的原子更新，Cassandra只能提供最终一致性。
但是事务的要求并不是必须的，许多数据，比如网络流量日志，社交网络状态更新(微博等)，广告点击，道路交通数据，交易数据和游戏分数等是一次写、多次读，这样的数据对事务的需求有限，甚至没有。
有些数据虽然已更新和删除，但是修改通常只限于单记录而非数据集的某个范围，有时更新非常频繁且涉及范围操作。如果范围操作很常见并且需要保持更新的一致性，那么RDBMS才是最佳选择，如果单个条目的原子性已经足够，那么列式数据库、文档数据库和部分键/值存储都可以。如果需要事务完整性但是可以容纳暂时的窗口不一致，那么最终一致性存储也是不错的选择。
3、 数据模型
MongDB支持类SQL查询、基本的关系型引用和数据库对象，如果使用NoSQL的主要原因是可以使用宽松的数据结构，那么MongDB肯定是开始使用NOSQL的最佳选择。
很多Web为中心的业务都开始使用MongDB，主要是因为它支持灵活的数据模型(弱Schema)，同时能够提供快速的读写能力。（现在敏捷开发很重要、MongoDB能更快地开发应用程序。一个明显的原因是MongoDB没有固定的Schema，所有花在提交、沟通和实施Schema变更的时间都省下来了）
此外MongDB对Web框架的支持非常好，比如Spring、Rails等。
最后要说明的是，MongDb非常容易上手，学习周期很短。
4、 查询支持
挑选NoSQL主要考虑的因素除了存储，还有查询。
MongDB和Redis的查询能力比较强。
像MongDB的查询，与SQL相似，语法简单，容易学习。MongoDB支持范围查询，正则表达式查询，对子文档内属性的查询，可以取代原来大多数任务的SQL查询。
像Redis的查询，查询方法很全，命令文档也很丰富。
Hbase只支持基于Rowkey的单条记录查找、基于Rowkey的范围查找以及全表扫描。
要注意的是几乎所有NoSQL存储都不支持表之间的join操作。
提到查询不得不提到索引，MongDB本身支持二级索引，Hbase不支持二级索引，但是现在也有很多方法(最常见是借助协处理器)可以帮助Hbase实时建立二级索引。
5、 性能
(1) 50/50读和更新、即读少写多。
Cassandra最优秀，每秒执行超过1W次操作，平均读延迟只有25ms、更新性能更好只有10ms。
Hbase紧随其后。至于MySQL，每秒执行4000左右操作的时候才和上面两个有可比性，超过5000之后延迟迅速攀升。
(2) 95/5读和更新、即读多写少。
还是Cassandra最优秀。
列式存储连续范围的读取性能非常优秀，这证明和Hbase批量读写的性能非常好。
Hbase表现非常稳定，与每秒操作数无关，5%的更新在Hbase里面几乎没有延迟。
只读情况下MySQL性能最好，可能与缓存有关。
如果结合分布式缓存MemeCached或者MemBase，那么Hbase的读取性能就可以和MySQL比肩了。
四、选择NoSQL存储需要考虑的维度
1、Data model（数据模型）. Thereare many variations of how the data is stored, which include key/value stores(compare to a HashMap), semi-structured, column-oriented stores, anddocument-oriented stores. How is your application accessing the data? Can theschema evolve over time?
2、Storage model（存储模型）.In-memory or persistent? This is fairly easy to decide on since we arecomparing with RDBMSs, which usually persist their data to permanent storage,such as physical disks. But you may explicitly need a purely in-memorysolution, and there are choices for that too. As far as persistent storage isconcerned, does this affect your access pattern in any way?
3、Consistency model（一致性模型）.Strictly or eventually consistent? The question is, how does the storage systemachieve its goals: does it have to weaken the consistency guarantees? Whilethis seems like a cursory question, it can make all the difference in certainuse-cases. It may especially affect latency, i.e., how fast the system canrespond to read and write requests. This is often measured harvest and yield.
4、Physical model（物理模型）.Distributed or single machine? What does the architecture look like - is itbuilt from distributed machines or does it only run on single machines with thedistribution handled client-side, i.e., in your own code? Maybe the distributionis only an afterthought and could cause problems once you need to scale thesystem. And if it does offer scalability, does it imply specific steps to doso? Easiest would be to add one machine at a time, while sharded setupssometimes (especially those not supporting virtual shards) require for eachshard to be increased simultaneously because each partition needs to be equallypowerful.
5、Read/writeperformance（读写性能）. You have to understand what your application‘s access patternslook like. Are you designing something that is written to a few times, but readmuch more often? Or are you expecting an equal load between reads and writes?Or are you taking in a lot of writes and just a few reads? Does it supportrange scans or is better suited doing random reads? Some of the availablesystems are advantageous for only one of these operations, while others may dowell in all of them.
6、Secondary indexes（二级索引）.Secondary indexes allow you to sort and access tables based on different fieldsand sorting orders. The options here range from systems that have absolutely nosecondary indexes and no guaranteed sorting order (like a HashMap, i.e., youneed to know the keys) to some that weakly support them, all the way to thosethat offer them out-of-the-box. Can your application cope, or emulate, if thisfeature is missing?
7、Failure handling（失败处理）. It isa fact that machines crash, and you need to have a mitigation plan in placethat addresses machine failures (also refer to the discussion of the CAPtheorem in Consistency Models). How does each data store handle server failures?Is it able to continue operating? This is related to the "Consistencymodel" dimension above, as losing a machine may cause holes in your datastore, or even worse, make it completely unavailable. And if you are replacingthe server, how easy will it be to get back to 100% operational? Anotherscenario is decommissioning a server in a clustered setup, which would mostlikely be handled the same way.
8、Compression（压缩）. Whenyou have to store terabytes of data, especially of the kind that consists ofprose or human readable text, it is advantageous to be able to compress thedata to gain substantial savings in required raw storage. Some compressionalgorithms can achieve a 10:1 reduction in storage space needed. Is thecompression method pluggable? What types are available?
9、Load balancing（负载均衡）. Giventhat you have a high read or write rate, you may want to invest into a storagesystem that transparently balances itself while the load shifts over time. Itmay not be the full answer to your problems, but may help you to ease into ahigh throughput application design.
10、AtomicRead-Modify-Write（原子读修改写操作）. While RDBMSs offer you a lot of these operations directly (becauseyou are talking to a central, single server), it can be more difficult toachieve in distributed systems. They allow you to prevent race conditions in multi-threadedor shared-nothing application server design. Having these compare and swap(CAS) or check and set operations available can reduce client-side complexity.Locking, waits and deadlocks It is a known fact that complex transactionalprocessing, like 2-phase commits, can increase the possibility of multipleclients waiting for a resource to become available. In a worst-case scenario,this can lead to deadlocks, which are hard to resolve. What kind of lockingmodel does the system you are looking at support? Can it be free of waits andtherefore deadlocks?
附上一些有用的网址：
MongDB介绍： http://www.csdn.net/article/2012-11-15/2811920-mongodb-quan-gong-lue
NOSQL数据库对比： http://vschart.com/compare/hbase/vs/mongodb
几种NoSQL性能对比： http://www.jdon.com/46128
参考：
1、淘宝的应用场景和优化：http://blog.csdn.net/jiyiqinlovexx/article/details/29260677。
2、淘宝大数据的相关PPT。
3、Facebook的论文。
4、HBase权威指南。