分布式存储系统地一些理解和实践.docx
《分布式存储系统地一些理解和实践.docx》由会员分享，可在线阅读，更多相关《分布式存储系统地一些理解和实践.docx（11页珍藏版）》请在冰豆网上搜索。
分布式存储系统地一些理解和实践
分布式存储系统的一些理解和实践
X建伟
一、分布式存储系统介绍
1.简介
互联网数据规模越来越大，并发请求越来越高，传统的关系数据库，在很多使用场景下并不能很好的满足需求。
分布式存储系统应运而生。
它有良好的扩展性，弱化关系数据模型，甚至弱化一致性要求，以得到高并发和高性能。
按功能分类，主要有以下几种：
✧分布式文件系统
hdfscephglusterfstfs
✧分布式对象存储
s3（dynamo）cephbcs（mola）
✧分布式表格存储
hbasecassandraoceanbase
✧块存储
cephebs（amazon）
分布式存储系统，包括分布式系统和单机存储两局部；不同的系统，虽在功能支持、实现机制、实现语言等方面是有差异的，但其设计时，关注的关键问题是根本一样的。
单机存储的主流实现方式，有hash引擎、B+树引擎和LSM树（LogStructuredMergeTree）三种，不展开介绍。
本文第二章节，主要结合hbase、cassandra和ceph，讲下分布式系统设计局部，需要关注的关键问题。
2.适用场景
各分布式存储系统功能定位不尽一样，但其适用和不适用的场景，在一定程度上是一样的，如下。
1）适用
大数据量〔大于100T，乃至几十PB〕
key/value或者半结构化数据
高吞吐
高性能
高扩展
2）不适用
Sql查询
复杂查询，如联表查询
复杂事务
二、分布式存储系统设计要点
1.数据分布
分布式存储，可以由成千甚至上万台机器组成，以实现海量数据存储和高并发。
那它最先要解决的就是数据分布问题，即哪些数据存储在哪些机器〔节点〕上。
常用的有hash类算法和用meta表映射两种方式。
一般完全分布式的设计〔无master节点〕，会用hash类算法；而集中式的设计〔有master节点〕用meta表映射的方式。
两者各有优缺点，后面讲到具体问题时再做比拟。
1）一致性hash
将存储节点和操作的key〔key唯一标识存储的object，有时也叫objectname〕都hash到0~2的32次方区间。
映射到如下环中的某个位置。
沿操作key的位置顺时针找到的第一个节点即为此key的primary存储节点。
如如下图所示：
图1一致性hash
Cassandra借鉴了dynamo的实现，用了一致性hash的方式。
节点的hash值〔也叫token〕，可以手动分配或者自动生成。
Key的hash值即md5（key）。
每个表可以在建表时指定副本数，当副本数为3时，找primary存储节点后，顺时针方向的下2个存储节点即为replica存储节点。
Hash类算法，优点是无需master节点，一个缺点是，不支持key的顺序扫描。
2）Crush算法
也是一种类hash算法，随着ceph诞生，也是ceph的一大亮点。
Crush算法比拟复杂，这里简化介绍下。
Ceph的每个Object最终都会映射到一组OSD中，由这组OSD保存这个Object，映射流程如下：
Object→PG→OSDset
∙OSD先理解为机器节点吧
∙PG即PlacementGroups，可以理解为存储在同一组OSD上的object的集合
Object先映射到PG（PlacementGroup），再由PG映射到OSDset。
每个表空间有固定数量的pg，在建表时指定。
每个Object通过计算hash值并对pg数量取模得到它所对应的PG。
PG再映射到一组OSD〔OSD的个数由表的副本数决定，也是建表时指定〕，第一个OSD是Primary，剩下的都是Replicas。
PG→OSDset的映射由几个因素决定：
∙CRUSHhash算法：
一种伪随机算法。
∙OSDMAP：
包含当前所有OSD的状态、OSD的机器机架信息等。
∙CRUSHRules：
数据映射的策略。
这些策略可以灵活的设置object存放的区域。
比如可以指定table1中所有objects放置在机架1上，所有objects的第1个副本放置在机架1上的服务器A上，第2个副本分布在机架1上的服务器B上。
table2中所有的object分布在机架2、3、4上，所有Object的第1个副本分布在机架2的服务器上，第2个副本分布在机架3的服器上，第3个副本分布在机架4的服务器上。
具体实现不再展开。
图2cephcrush算法
伪代码如下所示：
locator=object_name
obj_hash=hash（locator）
pg=obj_hash%num_pg
osds_for_pg=crush（pg）#returnsalistofosds
primary=osds_for_pg[0]
replicas=osds_for_pg[1:
]
Crush相比一致性hash更加灵活。
3）按range查表
由master节点记录和管理每个表range的粒度，以与每个range的数据存储在哪些节点上。
range是根据key的字节序确定。
Client在执行key存取操作是，先到master，根据其所在range，查询其存储在哪些节点；再直接跟存储节点交互，实现存取。
Hbase是用这种方式实现，支持key的顺序扫描。
如如下图所示，region即一段range的数据〔存储在materserver上〕，regionsever即实际存储节点。
图3hbaseregion映射
2.数据可靠性
数据可靠性，即数据不丢失，是存储系统的第一职责。
图4数据中心
分布式一般采用普通服务器，要假设服务器和硬盘都是不可靠的。
如何保证在有硬件损坏时数据不丢失，是任何分布式存储系统都必须考虑的。
已有做法有以下几种。
1）多副本
即数据保存N+1份〔一般是3份〕，每一份都存储在不同的节点上。
在数据损坏N份时，仍能修复数据。
缺点是，需N倍的冗余存储空间。
✧hbase、cassandra、ceph都很好的支持。
2）纠删码
即将一条数据切分成n等份，通过对这n份数据编码，得到m份相等大小的校验数据块儿。
这n+m份数据，各自存储在不同的节点上，拿到n+m中的任意n份数据，均可计算得到原始的数据。
一般n取10，m取3。
优点是，只需m/n倍的冗余空间，缺点是读写效率较低，且消耗cpu。
图5纠删码
✧Hbase：
hdfs层为hbase提供支持。
✧Cassandra：
社区版本不支持，社区还无添加此功能的路线图，之前社区有讨论过此功能，后来不了了之。
应该是主要考虑到纠删码方式对现有系统的存储结构、一致性语义都有较大影响，且性能较低。
✧Ceph：
支持。
但在功能上有些缺失，比如不支持partialread，适合读远多于写的场景，应用较少。
3）跨级群自动备份
一般为了更高的可靠性，数据会通过准实时备份机制，备份到另外一个IDC的存储集群。
✧Hbase：
社区版本已经支持。
✧cassandra和ceph：
都不支持，短期没有路线图，长远来讲，是需要添加的。
4）接入修复
客户端写数据到存储集群，一般先按一定规如此找到一个接入节点，再由次接入节点做proxy将数据写到实际存储的节点。
假设需要写入3副本，如果接入节点发现，有的副本对应的存储节点此时不可用，或者写超时，那么会将写失败的节点与未写成功的数据存储下来。
之后，定时或者收到通知不可用节点变为可用时，尝试写入之前未写成功的数据。
✧Hbase：
hdfs层会保证写入足够的副本，因为hdfs的namenode记录了每个block的meta数据〔block存储在哪些datanode〕，一个datanode写失败，换一个写，直至写成功。
可以看到，记录meta这种方式很灵活
✧Cassandra：
有hinthandoff机制，原理如上
✧Ceph：
有pglog机制，原理如上
5）全局扫描修复
用以修复磁盘损坏、误删文件等原因引起的数据丢失。
由master节点发起全局数据，或者primary节点发起自己负责的range的数据，的多个副本间的数据扫描。
如果发现某个副本缺失，如此进展修复。
Hbase、cassandra、ceph都有类似机制，原理类似，机制不同，这里不一一展开讲了。
✧Hbase：
hdfs层的datanode在发现盘损坏后，会收集剩下的所有block信息，并通知namenode比照修复
✧Cassandra：
基于Merkletree的anti-entropy机制
✧Ceph：
scrub和deep-scrub机制
3.可用性
分布式存储系统，相比传统关系数据库，有更好的可用性。
在个别机器硬件或软件故障，甚至整个机房断电断网等极端情况下，仍不影响在线读写。
对于个别机器硬件或者软件故障，一般数据保存多份副本或者纠删码方式就能解决。
对于整个机房断电，只能是多副本的跨idc存储，一般分布式存储系统都支持这种方式，只是目前实际应用的很少。
保证可用性，另外一个影响因素是，整个系统是否有单点故障。
完全分布式的设计是没有单点的。
集中式的设计，有meta信息，需要metaserver的角色，一般也会将metaserver做成集群式，以防止单点问题。
下面结合例子讲下。
1）分布式or集中式
✧Hbase：
metaserver是集群方式，通过zk的选举算法选出一个主节点来提供服务，主节点挂掉后，会重新选一个。
所以hbase的metaserver也不算是单点的。
但其regionserver是单点的，即一个regionserver挂掉，在master没有为其负责的region进展重分配前，这个region所负责的range，是无法提供在线读写的。
之所以存在此单点问题，猜想因为hbase设计之初，是为网页库这类离线存储设计的，而非在线服务。
另外，regionserver的这种设计能较方便是实现强一致性和简单事务，后面会提到。
现在貌似已有regionserver的standby机制，即一台regionserver挂掉，另一台准备就绪的能马上接替并提供服务。
Hbase架构如下：
图6hbase架构
✧cassandra和ceph：
是完全分布式的〔ceph虽有monitorserver，但仍可理解为完全分布式的，这里不展开了〕，无单点问题。
4.可扩展性
存储系统的可扩展性，即扩容的难易程度。
可扩展性是分布式系统相比传统关系数据库，最大的优势。
各分布式存储系统都能很好的支持横向扩展。
由于实现方式的不同，扩容的难易程度还是有差异的。
一般集中式的系统扩容更加容易，完全分布式的系统会更加麻烦些。
下面结合例子讲下。
1）扩容
✧Hbase：
比拟容易，扩容的大致过程为：
增加一些regionserver，由masterserver做一下balance，即重新确定regionserver与region的对应关系〔每个region负责一定X围的key，对应于hdfs上的一组文件〕，完全不需要拖数据。
而hdfs本身扩容也较容易，因为有namenode存在〔相当于masterserver，对写入hdfs的每个块儿都记录其存储节点〕，可以将新写入的文件写入到新扩容的server，这样不需要拖数据；如果要考虑写压力均衡〔即不把写压力集中在新参加的机器上，仍然写所有机器〕，仍需要做数据迁移。
✧Cassandra和ceph：
因为key定位是通过hash类算法，所以拖数据不可防止。
拖的数据量即新加的node所负责的数据量。
一致性hash和crush算法不同，导致拖数据的源节点不一样，但总的来说某某小异。
5.数据一致性
一致性分强一致性和最终一致性，解释如下：
强一致性：
写完一条数据key1，马上读key1，能读到最新数据。
最终一致性：
写完一条数据key1，马上读key1，可能读到老数据，但一段时间后，能够读到新数据。
最终一致性相比强一致性，有更高的性能。
一致性跟primary和replica在读写时的地位相关，不同系统在实现上会有不同的取舍，下面具体说明。
1）单主、多主、主从
✧Hbase：
regionserver是单点，可以理解问题单主方式，天然的强一致性。
✧Cassandra：
最终一致性，通过客户端一致性级别的设置也可实现强一致性。
Cassandra多个副本节点的地位一样，可以理解为多主方式，并列提供读写，这种方式读写性能很高，除了牺牲了强一致性，还有造成写冲突问题，cassandra通过column级别的时间戳解决此问题，但不彻底，时间戳一样时就没有方法了。
✧Ceph：
的多个副本间有主从关系，一主多从，客户端写主节点，主节点负责写从节点。
客户端只能读主节点。
以此实现强一致性。
Ceph也支持配置为本地化〔就近，不一定是主节点〕读方式，这种方式也牺牲了强一致性。
Ceph的块儿存储和分布式文件系统功能，要求它必须支持强一致性。
6.性能
前面已经提到，不同的一致性会对性能有影响。
另外，还有两点对对性能影响较大：
1）完全分布式or集中式
集中式架构需要有metaserver。
读操作先查metaserver，再向datanode查询真正的数据；写操作除更新datanode也可能要更新metaserver。
完全分布式读写如此少了与metaserver交互的过程。
所以延时更低。
且集中式，在数据量巨大或者压力很大时，metaserver有可能成为性能瓶颈，目前有metaserver分层、静态子树等解决方案。
✧Hbase：
是集中式的，但客户端维护metaserver的缓存，一般读写时无需网络查询metaserver，所以从hbase这层看，集中式并不影响其性能。
但hdfs层读写必须要namenode参与，所以性能低些。
Hbase+hdfs这种分层架构，有很多好处，但显然性能会逊一筹。
✧Cassandra：
是完全分布式的，客户端可以连接任一台node读写，这台接入node通过一致性hash定位真正负责此次读写的node，再进展读写。
效率要比hbase高些。
✧Ceph：
是完全分布式的，客户端通过monitorserver得到节点信息，缓存在本地，再通过crush算法，直接定位到主节点实现读写。
这个角度看，ceph的效果比cassandra更高些。
2）单机存储引擎
分布式存储一般采用LSMT引擎，将随机写转化为顺序写log和memtable〔内存〕方式，能极大提高写性能。
读操作，还是通过索引来提高性能。
分布式存储的数据模型一般是schema-less的，即不需要预先定义每行包括哪些列以与每个列的类型，多行之间允许包括不同的列；一般只有主key索引；不需考虑数据完整性约束〔比如外键约束〕、列类型约束、NOTNULL约束等；所以较适合用LSMT引擎实现，关系数据库如此不太适合。
Schema-less是分布式存储一般性能较高的原因之一。
图7LSMT
✧Hbase、cassandra、ceph都是wal的方式。
顺序写完journallog后，写实际数据。
写数据时，hbase和cassandra是写memtable〔源自bigtable吧〕，更多的减少随机写硬盘。
Ceph不是memtable的方式，直接写文件系统，并定时sync。
Memtable的方式对小value更加友好，但需要引入的paction，paction带来了更多的运维工作。
Ceph由于其块儿存储功能，经常会修改一个对象的某一小段，如果用memtable的方式，即使修改一小段，也要重写整个对象，效率比拟低。
7.易运维性
主要是扩容、顶替〔一台机器损坏，用另外一台机器代替之，可能涉与到迁移数据〕、升级、盘故障〔数据修复〕等操作的快速性和简单性。
存储机器一般是12*2T盘，现在极端一些有24*4T盘。
单机存储数据量是很大的。
扩容或者顶替一台机器，一般也要几个小时甚至1天的时间。
在这段时间内存储系统是处于副本缺失状态的，万一这段时间好的副本又出问题，后果可能很严重；所以，要尽量防止数据迁移或者缩短迁移时间。
1）扩容、顶替、升级
✧Hbase：
不考虑hdfs的话，其扩容、顶替更容易，因为不涉与迁移数据。
Hbase因单点问题，升级必然影响在线服务，这一点是一直在努力优化的，例如之前提到的regionserverstandby机制，hdfs的namenode的热备机制。
✧Cassandra：
由于其gossip广播的限制，较难做的很大，所以360有多达几十个cassandra集群，给运维带来不少工作量。
扩容和顶替因涉与到迁移数据，比拟麻烦，一般会绕过它，刚开始集群建设一步到位，后续不扩容，如果有机器损坏，直接修，而不是顶替。
Cassandra的升级比拟有优势，3副本的情况下，可以最多一次升级1/3的机器，而不影响在线读写。
✧Ceph：
还没搞过大集群，crush机制理论上可以将集群建的比拟大〔也许几千台〕，但扩容、顶替拖数据不可防止。
因为不能确定数据的几个副本在那几个节点上，或者说不能确定几台机器上是否有同一批数据的副本，所以，升级为了不影响在线服务，最好一台台升级。
2）磁盘故障
✧盘故障引起的数据修复，衡量其好坏的标准，就是是否够快、是否足够自动化。
磁盘写性能是修复速度的瓶颈。
全局修复机制都能够做到自动化。
所以，三种系统在这一点上差异不大。
8.复杂查询与事务
分布式存储系统相对于关系数据库之所以能做到高性能、高扩展，主要的原因之一就是选择不支持复杂的联表查询与事务操作。
联表查询，分布式存储系统一般都不支持，而是通过冗余存储的方式实现类似的功能需求。
复杂的事务，也不支持。
但简单的事务，如单行事务、CAS〔pare–and-set〕还是可以支持的。
1）事务
✧Hbase：
支持单行事务〔可以是多个操作〕，由于regionsever单点，可以在单机上较容易的实现。
这是regionserver单点的一个优势。
✧Cassandra：
支持单次操作行级锁；单个column的cas操作〔依赖paxos多机协商，较为复杂，效率低〕。
✧Ceph如此没有此类需求，自然不支持。
以上有些是实践总结，有些如此加了自己的理解，有不对之处，还请指出，多谢。
升级会员 