Upload
li-daobing
View
74
Download
2
Embed Size (px)
Citation preview
七⽜牛为什么要做云存储?• 客户是谁?
• 有存储需求的⼈人(典型情况: 图⽚片,⾳音频,视频应⽤用,⽇日志存储和分析)
• 价值如何体现?
• 他们⾃自⼰己搞定这个事情的成本是多少?
• 前景如何?
• 世界上的新增数据以每年66%的速度增⻓长,。。。
我们为什么需要⼀一个公有云?
• 我把数据放在磁盘⾥里,磁盘做RAID5 是不是就可以了?
• 单点故障,如果机器损坏或者需要停机,这些数据就下线了
• IOPS和吞吐量都很有限
• 容量有限,放满了这个⽅方案就不合适了
• 听说 glusterfs 不错,是否可以解决这个问题
glusterfs 的问题• 优点
• POSIX兼容,很多程序不⽤用修改就可以直接⽤用
• ⽆无中⼼心的架构,机器数量不受限制
• 缺点
• ⽆无中⼼心的架构天⽣生的两个缺点: a. 扩容时rehash导致⼤大量数据迁移 b. 对称盘的形式导致修复速度太慢
• 数据链路过⻓长,所以⼩小⽂文件性能超差
• 实现的API过多,导致实现复杂度很⾼高
• 适⽤用领域: ⼩小规模集群,容量可预估,没有⼩小⽂文件,程序很难改造成⽤用 API 来访问存储
mogilefs 的问题• 优点
• 有中⼼心,扩容和修复更⽅方便
• 缺点
• 有中⼼心的缺点:
• 总条⺫⽬目数受中⼼心限制
• 读写速度受中⼼心限制
• ⼤大⽂文件上传不⽅方便
• 适⽤用领域
• 中⼩小型⺴⽹网站,⽂文件数量不超过⼏几千万,1PB左右的规模,访问频率不超过⼏几千QPS,不⽤用考虑⼤大⽂文件上传的问题。
Hadoop 的问题• 优点
• 超强的伸缩性,1000台规模⽆无压⼒力,5000台阿⾥里也有⼀一些实践
• 缺点
• Hadoop 是按照离线数据分析服务来设计的
• 可⽤用性低: Java语⾔言本⾝身的问题,Hadoop 数据平衡时数据访问超时
• ⼩小⽂文件⽀支持不好,hadoop 的数据块太⼤大
• 适⽤用领域:
• 离线数据分析:各类⽇日志分析,数据报表类的业务
混搭模型• HBase
• Hadoop+HBase/MySQL
• RawDisk+MySQL
• …
• 简单来说,做⼀一个⽀支持 1PB 的云存储已经不是什么难事了,剩下的⼤大问题只有⼀一个: 运维
你有⾜足够强的运维么?• 为什么需要运维
• 机器坏,磁盘坏
• 磁盘满,⺴⽹网络满,磁盘过载,内存不⾜足
• ⺴⽹网络不稳,交换机死机,。。。
• 安全更新
• 为什么哪些软件不把这些全部做到业务逻辑⾥里边去
• 有些很难做(⽐比如⺴⽹网络,交换机,磁盘满,安全更新)
• 防⽌止系统过敏(⽐比如上次亚⻢马逊机房事故就是⼀一次过敏)
• 研发和稳定期很⻓长
• 不想⼤大幅度增加架构的复杂度
你需要更多基于云存储的服务
• 图⽚片:缩放,⽔水印,原图保护
• ⾳音视频:转码,切⽚片,合成,快速预览
• 你的⾃自定义需求: 美颜相机,⼈人脸识别,数据统计
• ⽽而这些需求在跟私有云整合时开发⼯工作量很⼤大,⽽而对于很多云存储这些功能都是现成的
七⽜牛为什么要做云存储?
• 客户+价值+前景 // 公司的⽴立⾝身之本
• 有技术⻔门槛 // 不会变成红海
• 很酷 // ⼤大家干得很开⼼心
• 创业加速器 // 看到⼀一堆新公司在⾃自⼰己的平台成⻓长起来很开⼼心
单机房100PB的挑战• 4000台存储机,不考虑冗余每台要承担 25TB 的容量
• 200KB的⽂文件平均⼤大⼩小情况下,如何去⽀支持 5000亿条元数据
• 元数据集群如何去⽀支持1Mqps 的请求频率
• 除了这些还有...
单机房100PB的挑战• 架构也许不是那么难
• 保持每个组件都是⾼高可⽤用,可伸缩的
• 保持每个远程调⽤用都是可重⼊入的
• ⺴⽹网络传输需要校验
• 。。。
• 难得是规模⼤大了之后的⼀一个问题
• 墨菲定律:凡是可能发⽣生的,就⼀一定会发⽣生
Summary• ⾃自建云存储的缺点
• 运维成本⾼高,相⽐比购买云服务,并不划算
• 常规解决⽅方案存在适⽤用领域狭窄的问题,不够通⽤用
• 七⽜牛云存储的优点
• 运维外包,成本更低,安全性可⽤用性更好
• 更多的扩展功能