云存储系统需求分析

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

大数据存储需求

管理需求

●动态添加删除用户

●用户容量控制

●用户流量,网速控制

●用户副本灵活配置

性能需求

●响应时间

●Iops指标

●吞吐量指标

稳定性

●24小时无故障服务

●大数据量情况iops指标无明显变动

●大数据量下吞吐量指标无明显变化

●系统负载在一定阀值下服务

●监控系统完善主要是对cpu,内存,网络,io

容错高可用

●在无自然灾害性的真个机房出现故障的情况下24小时服务●系统奔溃后可恢复服务

●容灾备份

可扩展性

●支持在线横向扩容

●支持在线纵向扩容

●节点自动感知

数据格式支持

●二进制小文件

●图片文件

●视频文件

●大文件

●大文件随机读

●大文件随机写(不容易实现)

接口

●大小文件支持类posix的接口

●支持rest接口(前期不一定实现)

●最好能支持读写分离的锁

测试

●写测试

●随机写测试

●读测试

●随机读测试

●并发读写测试

●上量读写测试

●测试平台

分布式测试平台本质是一个必行任务系统,可以有多种的实现方式,原理如下如

由控制节点发出测试开始的指令,测试机根据挂载的测试任务,进行并发测试,结束后,将结果返回给任务分发机器,经过统计,返回给测试任务控制机

实现方式:

●使用自动化测试框架(未使用过)

●自写并行任务分发系统,进行测试

●利用hadoop等开源软件进行测试,入mapreduce,可以再map中进行测试任务,由

reduce汇总测试结果,reduce个数设置成1

整体框架

灰色表示第一版本不需要实现的部分,现在需要是先的部分部署的部分主要是在分布式存储和开放服务以及上层的接口

Linux

资源管理安全管理

远程过程调用分布式协同服务

分布式存储任务调度

计算服务开放存储服务半结构化数据存

数据处理服务

关系型数据缓存统计存储处理接口

Fuse 接口基准测试平数据处理服务

自动部署

监控系统

持久化存储服务

图片应用需求

● 创建用户

● 创建命名空间,即文件夹

● 创建操作员,该操作员只能操作指定的用户空间 ● 上传,下载,删除,获取图片属性,清除缓存 ● 图片类型识别,动态转换

设置图片特有格式 如http 请求http :///xx.jpg,可用http :///xx.jpg !small 访问small 格式的图片,small 格式定义为:10*5的图片,或是其他类型,如等高,等宽等

● 每一个命名空间可以有不同的格式限定 ● 实时性保证 为支持如相册

实现方法

根据图片的特性和和应用,图片存储主要是得结构是如下

图片存储集群

图片上传图片

下载

服务

图片

下载

服务

图片上传服务器

图片

处理

服务

图片

处理

服务

器下载

服务

上传客户端

上传

客户

上传

客户

端缓存

服务

缓存

服务

缓存

服务

缓存

服务其中黑色线条表示在实现中可不必实现。例如,某张图片原图格式是jpeg,1024*768大

小,在请求是的时候请求的是200*100的大小,请求图片存储时并没有需要的的大小,需要经过转换,缓存服务拿到原图,在图片处理服务处理后,将处理后的图片缓存在本地的缓存中,因为这类的请求,并不是持久性的请求,比如客户页面在更改,第一版按照200宽的等宽显示,两天后,客户页面修改,将缩略图改为300等宽,这样,如果存储到图片存储中,因为前端的修改,图片请求的格式在不断的变化,如果存储起来,会浪费很多存储空间,这种变化的可能会导致存储的数十倍的浪费

分布式系统

分布式系统是需要的,主要是两个方面,第一是自动进行冗余备份,其次是提供动态扩容的方便,选择合适的分布式系统是比较好重要的

前置机

在图片存储服务,甚至大部分的文件存储服务中,读写的差异很大,读写请求的数量差异也很大,一张图片,写次数屈指可数,读的次数多大千万次,读服务请求的数量也很多,读写请求的完成质量也有差异,写请求失败,数据很有可能丢失,或者造成一段时间内整体读服务不能完成。而读请求失败一次,影响却很小,可以通过其他节点,或者备份节点弥补,所以在上面的架构体系统,将读写请求分开以前置机来出来。

方案

Tfs或者fastdfs

这个用作用图片存储的优点是这两个系统开发意图就是为了图片存储,也为图片存储做了大量的优化,对大量小图片的支持很好,访问速度,稳定性,数据一致性保证都很好。都不需要二次开发,直接可以使用,并且提供了nginx的模块,可以很容易配置http访问方式。

缺点是都不支持posix类接口,实质是属于key-value类型接口

在作为云端存储的时,需要在外围做大量的开发工作,维护user-namespace-pic的关系使用如kv方式存储

底层是用大型的分布式文件系统,上层是用key-value存储存储文件的方式也可以对百亿级别的图片文件进行存储,但是文件需要经过切片进行存储,如果切片大小4k,常规图片的大小是20k左右,比如图片是21k,可以通过将图片文件切成4k固定的大小,分prefix+0-6的方式存入key-value存储中,并且将相应的图片数据存入对应的顺序的key中,在读取图片的时候,将6个key取出,按照顺序组个数据,即可还原图片。

Kv方式也可以是用bitcast方式存储文件,即图片存在文件里,kv只存储文件名到元数据的以及数据位置的索引,但是在合并时需要做额外很多的处理,比如图片的删除,需要从kv中删除,并且从数据文件中删除图片的那段数据,合并需要额外的调度,kv系统的自动合并并不能满足需求

大文件存储需求

●副本数个性设置

●多用户请求支持

●随即读支持,支持客户端请求文件内任意位置任意长度的数据

●断点续传功能

●校验功能

大文件存储的几个问题

文件分块

支持文件分块,为随即读提供分块机制,可以多副本情况下,可以提供多机并行读取,副本可在集群中自动分配,并自我修复,如果出现某台服务器宕机,副本可以再其他机器复制副本,保证数据的安全和向外提供服务的性能

相关文档
最新文档