19.5.2　MySQL VS Hadoop+HBase

面对Facebook中任务对存储系统的要求，Facebook如何选择呢？

1.MySQL

MySQL是比较流行的一款开源数据库，它轻巧简便。Facebook在最初使用MySQL+Memcached构建存储层，MySQL集群数据库作为底层存储，Memcached构建数据缓存层。这样既发挥了MySQL存储系统较高的随机读效率及其简单好用等特点，又通过Memcached缓存层在高访问量下提高了系统的访问效率。

但是Facebook在发展过程中逐渐发现，MySQL在数据量剧增和新应用上线提供服务情况下并不能像之前那样完美地工作。主要是MySQL集群有以下问题：随机写操作效率低、可扩展性差、管理成本和硬件成本高、负载均衡并不理想等。而这些缺点恰巧正是Facebook中海量数据所带来的系统需求。所以目前Facebook已经放弃MySQL+Memcached构建的存储层，而转向了Hadoop+HBase。

2.Hadoop+HBase

Facebook在发展过程中发现MySQL构建的存储层并不能完全满足系统的需求后，就开始审视到底什么样架构的存储层能够最大程度上满足Facebook的需求。

经过大量地研究和实验之后，Facebook最终选择使用Hadoop和HBase来作为下一代底层存储系统。这主要是基于：

1）HBase的特点满足Facebook对存储系统的需求。HBase基于列存储分布式的开源数据库能满足系统海量数据存储的需求和高扩展性的需求，同时HBase能够保证高吞吐的写操作。它是一个能够实现快速随机和流读取操作的分布式存储系统。虽然不支持传统的跨行事务，但HBase面向列的存储模型在数据存储上提供了很高的灵活性并且支持表内的复杂索引。同时HBase对于写密集的事务是一个理想的选择，它能够维护大量的数据，支持复杂索引，具有灵活的伸缩性，它还能提供行级别的原子性保证。

2）Facebook有信心解决HBase在现实使用中存在的问题。HBase现在已经能够提供高一致性、高写吞吐率的键值存储。现有的HDFS NameNode作为管理的中心可能成为系统的瓶颈。Facebook的HDFS团队决定构建一个高可用的NameNode（在Facebook中称为AvatarNode），这对于数据仓库操作也将非常有用。这样好的磁盘读效率就可以满足（向HBase的LSM树中添加Bloom filter，使本地DataNode能够高效地执行读操作并且缓存NameNode的metadata）。在系统故障和容错方面，HDFS能够在磁盘子系统中容忍和隔离故障。整个HBase/HDFS集群的故障是系统容错的一部分，可以考虑将数据迁移到较小的HBase集群中。HBase社区中对“复制”这块内容提供的是一个预定义的路径，用来解决灾难性的故障。

所以整体来说，采用Hadoop+HBase的存储架构，并通过Facebook根据自己需求进行局部的优化和改进之后，这样的存储架构能够满足系统绝大部分需求，提供稳定、高效、安全的存储服务。