Facebook Haystack图片存储架构 | NOSQL Notes
OSDI 10中有一篇Facebook图片存储系统Haystack的论文，名称为"Finding a needle in Haystack: Facebook's photo storage"。从这篇论文可以看出，数据量大的应用有时也并不复杂。
我们先给Facebook图片存储系统算一笔账。Facebook目前存储了260 billion图片，总大小为20PB，通过计算可以得出每张图片的平均大小为20PB / 260GB，约为800KB。用户每周新增图片数为1 billion (总大小为60TB)，平均每秒钟新增的图片数为10^9 / 7 / 40000 (按每天40000s计)，约为每秒3500次写操作，读操作峰值可以达到每秒百万次。另外，图片应用的特点是写一次以后图片只读，图片可能被删除但不会修改。
图片应用系统有两个关键点：
1, Metadata信息存储。由于图片数量巨大，单机存放不了所有的Metadata信息，假设每个图片文件的Metadata占用100字节，260 billion图片Metadata占用的空间为260G * 100 = 26000GB。
2, 减少图片读取的IO次数。在普通的Linux文件系统中，读取一个文件包括三次磁盘IO：读取目录元数据到内存，把文件的inode节点装载到内存，最后读取实际的文件内容。由于文件数太多，无法将所有目录及文件的inode信息缓存到内存，因此磁盘IO次数很难达到每个图片读取只需要一次磁盘IO的理想状态。
3, 图片缓存。图片写入以后就不再修改，因此，需要对图片进行缓存并且将缓存放到离用户最近的位置，一般会使用CDN技术。
Read full article from Facebook Haystack图片存储架构 | NOSQL Notes
No comments:
Post a Comment