键-文件存储系统weedfs

zenlife · · 3662 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

2012-12-31

键-文件存储系统weedfs

weedfs 是跟据facebook的一篇论文 用go语言实现的key-file存储系统。
论文中facebook面临海量的photo存储,数据特点是一次写,读频繁,无修改,很少删除。 分析基于POSIX系统在此应用场景中主要的问题是元信息存储在磁盘,读元信息的磁盘IO成为性能瓶颈-- 第一次(可能是多次)读盘将文件名转为i结点,第二次读盘读入i结点,第三次读盘才是读数据。

设计目标:

  • 高吞吐低延时 元信息全部存储在内存,避免多次的磁盘IO
  • 容错
  • 简单

facebook的原始设计
../img/facebook_photo_storage.jpg

浏览器请求被重定向到CDN,CDN中如果缓存了该图片则直接返回,否则查询Photo存储服务器。 Photo存储服务器是用NFS搞的,他们改了内核做了个文件描述符的缓存open_by_filehandle,用 memcache缓存打开的文件描述符,避免多次读盘

存在的问题是,缓存效果并不好: CDN中图片的访问频率存在“长尾效应”,缓存命中的只有一部分,长尾要耗很大的带宽 Photo存储服务器的缓存,效果不明显。即使有缓存也无法改变POSIX读操作需要多次磁盘操作的本质问题

多张照片存储在一个大文件里,减少文件个数
减少元数据信息,将元数据全放在内存,像权限什么的,对于该应用场景就是不 必要的
../img/facebook_photo_haystack.jpg

按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一般是刚传上来时访问比较多


有疑问加站长微信联系(非本文作者)

本文来自:zenlife的博客

感谢作者:zenlife

查看原文:键-文件存储系统weedfs

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

3662 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传