​1. 为什么会引入分布式存储技术

从70年代到2000年左右，数据存储基本上是伴随着IBM E.F.Code提出的关系模型理论，以关系型数据库（Oracle、DB2、MySQL）为数据管理平台，以集中式存储产品为数据最终载体形成的坚实的数据存储架构体系。2000年后，但是随着数据量的增加，单机的数据库瓶颈已经不能满足大数据量的需求，从数据管理层面开始诞生分库分表的方案。自2006年谷歌发了三篇论文（GFS、Big Table、Map-Reduce）之后，在数据管理层面以及数据载体层面不断涌现各类分布式产品，例如GFS、GPFS、HFS、DFS等各类分布式文件系统，例如Hadoop、Hbase、Redis、MongoDB、RockDB等系列分布式数据管理平台。

总而言之，数据量的爆发式增长催生了数据应用领域的各种新需求，数据应用领域的各种新需求驱动了数据管理层面以及数据载体层面的分布式变革。

2. 主流分布式文件系统技术分析

主流分布式文件系统技术主要有GPFS、GFS、HDFS、DFS、ClusterFS等很多，下面我们以同类或类似技术体系的典型产品为代表进行阐述。

2.1 GFS

GFS是基于文件系统实现的分布式存储系统，是属于有中心的分布式架构；通过对中心节点元数据的索引查询得到数据地址空间，然后再去数据节点上查询数据本身的机制来完成数据的读写；是基于文件数据存储场景设计的架构。

接下来，我们来看GFS有哪些具体特性，选型的时候应该如何考虑？

(1) GFS是一种适合大文件，尤其是GB级别的大文件存储场景的分布式存储系统。

(2) GFS非常适合对数据访问延迟不敏感的搜索引擎服务。

(3) GFS是一种有中心节点的分布式架构，Master节点是单一的集中管理节点，即是高可用的瓶颈，也是可能出现性能问题的瓶颈。

(4) GFS可以通过缓存一份部分Metadata到Client节点，减少Client与Master的交互。

(5) GFS的Master节点上的Operation log和Checkpoint文件需要通过复制方式保留多个副本，来保障元数据以及中心管理功能的高可用性。

2.2 HDFS

HDFS的架构原理与GFS基本类似，但是是基于GFS做了一些改进之后形成的一套技术体系。同样，它基于文件系统实现的分布式存储系统，是属于有中心的分布式架构；通过对中心节点元数据的索引查询得到数据地址空间，然后再去数据节点上查询数据本身的机制来完成数据的读写；是基于文件数据存储场景设计的架构。

接下来，我们来看HDFS有哪些具体特性，选型的时候应该如何考虑？

(1) HDFS的默认最小存储单元为128M， 比GFS的64M更大。

(2) HDFS不支持文件并发写，对于单个文件它仅允许有一个写或者追加请求。

(3) HDFS从2.0版本之后支持两个管理节点（NameNode），主备切换可以做到分钟级别 。

(4) HDFS更适合单次写多次读的大文件流式读取的场景。

(5) HDFS不支持对已写文件的更新操作，仅支持对它的追加操作。

2.3 GlusterFS

GlusterFS虽然是基于文件系统的分布式存储技术，但是它与GFS架构有本质的区别，它是去中心化的无中心分布式架构； 它是通过对文件全目录的DHT算法计算得到相应的Brike地址 ，从而实现对数据的读写，这与GFS以及HDFS等通过元数据检索实现数据寻址的方式有极大的不同。

接下来，我们来看GlusterFS都有哪些具体特性，选型的时候应该如何考虑？**

(1) GlusterFS是采用无中心对称式架构，没有专用的元数据服务器，也就不存在元数据服务器瓶颈。元数据存在于文件的属性和扩展属性中。

(2) GlusterFS可以提供Raid0、Raid1、Raid1+0等多种类型存储卷类型。

(3) GlusterFS采用数据最终一致性算法，只要有一个副本写完就可以Commit。

(4) GlusterFS默认会将文件切分为128KB的切片，然后分布于卷对应的所有Brike当中。所以从其设计初衷来看，更适合大文件并发的场景。

(5) GlusterFS 采用的DHT算法不具备良好的稳定性，一旦存储节点发生增减变化，势必影响卷下面所有Brike的数据进行再平衡操作，开销比较大。

(6) GlusterFS文件目录利用扩展属性记录子卷的中brick的hash分布范围，每个brick的范围均不重叠。遍历目录时，需要获取每个文件的属性和扩展属性进行聚合，当目录文件较多时，遍历效率很差。

3. 主流分布式对象存储技术分析

目前应用比较广发的分布式对象存储技术基本都是基于Swift或者Ceph体系衍生出来的产品。

3.1 Ceph

Ceph首先是一种对象存储技术，也就是说它存储数据的机制与我们之前接触的文件系统机制是完全不一样的，它是将数据抽象为对象和对象标识来进行管理。 从架构上来讲，Ceph相对类似于GlusterFS的无中心化架构；它是通过对对象的哈希算法得到相应的Bucket&Node地址，从而实现对数据的读写 。

接下来，我们来看Ceph都有哪些具体特性，选型的时候应该如何考虑？

(1) Ceph是一种统一了三种接口的统一存储平台，上层应用支持Object、Block、File。

(2) Ceph采用Crush算法完成数据分布计算，通过Tree的逻辑对象数据结构自然实现故障隔离副本位置计算，通过将Bucket内节点的组织结构，集群结构变化导致的数据迁移量最小。

(3) Ceph保持数据强一致性算法，数据的所有副本都写入并返回才算写事务的完成，写的效率会差一些，所以更适合写少读多的场景。

(4) Ceph对象保存的最小单元为4M，相比GFS&HDFS而言，适合一些小的非结构化数据存储。

3.2 Swift

Swifty也是是一种对象存储技术，它与Ceph的架构有类似的地方，也是 无中心化架构；它是通过对对象的哈希算法得到相应的Bucket&Node地址，从而实现对数据的读写 。但是Swift是需要通过Proxy节点完成与数据节点的交互，虽然Proxy节点可以负载均衡，但是毕竟经历了中间层，在并发量较大而且小文件操作量比较的场景下，Ceph的性能表现会优秀一些。

接下来，我们来看Swift都有哪些具体特性，选型的时候应该如何考虑？

(1) Swift只保障数据的最终一致性，写完2个副本后即可Commit，这就导致读操作需要进行副本的对比校验，读的效率相对较低。

(2) Swift采用一致性哈希算法完成数据分布计算，通过首次计算对象针对逻辑对象（Zone）的映射实现数据副本的故障隔离分布，然后通过哈希一致性算法完成对象在Bucket当中的分布计算，采用Ring环结构组织Bucket节点组织，数据分布不如Ceph均匀。

(3) Swift 需要借助Proxy节点完成对数据的访问，不同通过客户端直接访问数据节点，相对数据的访问效率来讲，比Ceph要差一些( 可以参照ICCLAB&SPLAB的性能测试报告 )。

4. 主流分布式数据库技术分析

目前在分布式数据库技术的应用场景下，各行各业采用的产品比较多，尤其是NOSQL&NewSQL领域。记下来我们以文档、健值、内存、列式等几个典型分类来进行阐述。

4.1 MongoDB

MongoDB是以二进制JSON 或叫BSON 格式存储文档数据 为数据模型 ，专门为文档存储设计。当查询MongoDB并返回结果时，这些数据就会转换为易于阅读的数据格式。它的所谓分布式主要是指它的切片集群机制。通过基于范围的分区机制来实现水平扩展，称为分片机制，它可以自动化管理每个分布式节点存储的数据。

接下来，我们来看MongoDB都有哪些具体特性，选型的时候应该如何考虑。

(1) MongoDB面向集合存储，模式自由，易存储对象类型的数据，文件存储格式为JSON，从这个角度来讲，我们需要从数据业务场景角度去剖析其与MongoDB数据模型的契合性。

(2) MongoDB使用高效的二进制数据存储，包括大型对象，因此比较适合媒体、视频之类的大对象的存取场景。

(3) MongoDB支持支持动态查询，支持完全索引，支持RUBY，PYTHON，JAVA，C ，PHP，C#等多种语言，因此它与前端应用匹配的灵活性很强，适用于很多场景。

(4) MongoDB水平扩展能力较强，可以通过分布式集群架构将数据分布到多台机器，并且有完善的支持复制和故障恢复机制，支持海量数据的处理场景。

4.2 Redis

Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、 可基于内存 、分布式、可选持久性的 键值对(Key-Value)存储数据库 ，并提供多种语言的API。Redis 通常被称为数据结构服务器，因为值（value）可以是字符串(String)、哈希(Hash)、列表(list)、集合(sets)和有序集合(sorted sets)等类型。

接下来，我们来看Redis都有哪些具体特性，选型的时候应该如何考虑？

(1) Redis所有数据是存放在内存中的，源代码采用C语言编写，距离底层操作系统更近，并且使用单线程架构，避免了多线程可能产生的竞争开销。以上决定了它是执行速度非常快的数据库。

(2) Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。结合这个相对比较灵活的数据模型，Redis通常被用来作为高速缓存使用。

(3) Redis提供两种持久化方案AOF和RDB，因此它不仅仅适合高速缓存场景，而且适合基于此需求的衍生性业务场景。

(4) Redis从3.0版本后开始支持集群模式，很好的实现了处理能力的水平扩展，结合它的速度快的特性，这就为互联网电子商务的高并发场景提供了解决方案。

4.3 Hbase

Hbase 是 Google Bigtable 的开源实现，与 Bigtable 利用 GFS 作为其文件存储系统类似，HBase 利用 Hadoop HDFS 作为其文件存储系统; 运行 MapReduce 来处理 Bigtable 中的海量数据。因此从源头来看，Hbase是为大数据处理提供的数据存取解决方案，可称为列式数据库。

接下来，我们来看Hbase都有哪些具体特性，选型的时候应该如何考虑。

(1) Hbase 与很多面向行存储的关系型数据库不同，HBase 是面向列的存储和权限控制的，它里面的每个列是单独存储的，且支持基于列的独立检索。因此它天然适合分析类应用（OLAP）。

(2) HBase 中的数据都是以字符串形式存储的，为空的列并不占用存储空间，因此 HBase 的列存储解决了数据稀疏性的问题，通常可以设计成稀疏矩阵，在很大程度上节省了存储开销。

(3) HBase 的单表容量非常大，可以有百亿行、百万列，可以在横向和纵向两个维度插入数据，具有很强的弹性。HBase 采用 LSM 树作为内部数据存储结构，这种结构会周期性地将较小文件合并成大文件，以减少对磁盘的访问。这些特性尤其适合单表数据量巨大的数据存取场景。

5. 总结与展望

通过对分布式存储技术架构体系的综述分析，我们首先区分了不同技术体系究竟是应该用在数据管理场景还是数据载体场景。随后我们通过对不同体系的分布式存储技术典型产品特性的分析，明确了不同技术产品的数据模型、数据访问、数据性能、数据量级等不同层面的优劣势，最终希望通过这些典型特性的了解以及对具体业务场景的数据需求挖掘，能将比较优秀的数据存储技术匹配到最合适的业务场景中。​