键-文件存储系统weedfs
2012-12-31
键-文件存储系统weedfs
weedfs 是跟据facebook的一篇论文 用go语言实现的key-file存储系统。
论文中facebook面临海量的photo存储，数据特点是一次写，读频繁，无修改，很少删除。
分析基于POSIX系统在此应用场景中主要的问题是元信息存储在磁盘,读元信息的磁盘IO成为性能瓶颈--
第一次(可能是多次)读盘将文件名转为i结点，第二次读盘读入i结点，第三次读盘才是读数据。
设计目标：
- 高吞吐低延时 元信息全部存储在内存，避免多次的磁盘IO
- 容错
- 简单
facebook的原始设计
浏览器请求被重定向到CDN,CDN中如果缓存了该图片则直接返回，否则查询Photo存储服务器。 Photo存储服务器是用NFS搞的，他们改了内核做了个文件描述符的缓存open_by_filehandle，用 memcache缓存打开的文件描述符，避免多次读盘
存在的问题是，缓存效果并不好： CDN中图片的访问频率存在“长尾效应”，缓存命中的只有一部分，长尾要耗很大的带宽 Photo存储服务器的缓存，效果不明显。即使有缓存也无法改变POSIX读操作需要多次磁盘操作的本质问题
多张照片存储在一个大文件里，减少文件个数
减少元数据信息，将元数据全放在内存，像权限什么的，对于该应用场景就是不
必要的
按volume，不同机器上的物理volume再划分成逻辑的volume，Directory维护逻
辑到物理的映射;
Cache作用跟原来CDN一样，主要是缓存和单点故障，不过是系统内部的;
生成URL如
http://<CDN>/<Cache>/<Machine id>/<Logical volume, Photo>
Directory作用:
- volume的逻辑物理映射
- volume的读写负载均衡
- volume满的时候，标记为只读
Cache是分布式hash表实现，照片id是key
只缓存来自user的请求，不缓存来自CDN的，因为CDN miss了，内部缓存命中的
可能性也不大。
只缓存可读的volume，因为应用场景中，photo一般是刚传上来时访问比较多
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
