可扩展的图像存储

我目前正在为基于Web的应用程序设计架构,该架构还应提供某种图像存储.用户可以将照片上传为服务的关键功能之一.同时查看这些图像将是主要用途之一(通过网络).

但是,我不确定如何在我的应用程序中实现这种可伸缩的图像存储组件.我已经考虑过不同的解决方案,但由于缺少经验,我期待听到您的建议.除了图像之外,还必须保存元数据.以下是我最初的想法:

使用像HDFS这样的(分布式)文件系统,并将专用的Web服务器准备为"文件系统客户端",以便保存上传的图像和服务请求.图像元数据保存在附加数据库中,包括每个图像的文件路径信息.

在HDFS之上使用像HBase这样的面向BigTable的系统,并将图像和元数据保存在一起.同样,Web服务器桥接图像上传和请求.

使用像CouchDB这样的完全无模式数据库来存储图像和元数据.此外,使用基于HTTP的RESTful API将数据库本身用于上载和发送.(附加问题:CouchDB确实通过Base64保存blob.但它能否以image/jpeg等形式返回数据)？

max.. 43

我们一直在使用CouchDB,将图像保存为"附件".但是一年后,数十个GB CouchDB数据库文件变得令人头疼.例如,如果使用非常大的文档大小,CouchDB复制仍然存在问题.

所以我们只是重写了我们的软件,使用CouchDB获取图像信息,使用Amazon S3实现图像存储.该代码可从http://github.com/hudora/huImages获得

您可能希望为项目在现场设置与Amazon S3兼容的存储服务.这使您保持灵活性,并且不需要外部服务就可以保留亚马逊选项.Walruss似乎成为最受欢迎和可扩展的S3克隆.

我还恳请您通过他们出色的开源MogileFS和Perlbal产品来研究Livejournal的设计.这种组合可能是最着名的图像服务设置.

另外,Flickr的架构可以是一个灵感,虽然他们没有提供的开源软件给公众,如LiveJournal的一样.

1> max..：

---

我们一直在使用CouchDB,将图像保存为"附件".但是一年后,数十个GB CouchDB数据库文件变得令人头疼.例如,如果使用非常大的文档大小,CouchDB复制仍然存在问题.

所以我们只是重写了我们的软件,使用CouchDB获取图像信息,使用Amazon S3实现图像存储.该代码可从http://github.com/hudora/huImages获得

您可能希望为项目在现场设置与Amazon S3兼容的存储服务.这使您保持灵活性,并且不需要外部服务就可以保留亚马逊选项.Walruss似乎成为最受欢迎和可扩展的S3克隆.

我还恳请您通过他们出色的开源MogileFS和Perlbal产品来研究Livejournal的设计.这种组合可能是最着名的图像服务设置.

另外,Flickr的架构可以是一个灵感,虽然他们没有提供的开源软件给公众,如LiveJournal的一样.

2> Robert Newso..：

---

"其他问题:CouchDB确实通过Base64保存blob."

CouchDB的并没有为Base64,它们被存储为标准二进制保存的斑点.在检索JSON文档时,?attachments=true我们会将磁盘上的二进制文件转换为Base64,以便将其安全地添加到JSON,但这只是一个表示级别的事情.

请参阅独立附件.

CouchDB为附件提供与其存储的内容类型,实际上通常可以直接向浏览器提供服务器HTML,CSS和GIF/PNG/JPEG附件.

附件可以流式传输,在CouchDB 1.1中,甚至支持Range标头(用于媒体流和/或恢复中断的下载).

---

CouchDB从未将附件存储为Base64.可能误导您的是能够让CouchDB使用您文档的JSON返回附件.要做到这一点,有必要将它们包装在Base64中.在磁盘上,它始终是真正的字节.

3> chrislusf..：

---

使用Seaweed-FS(以前称为Weed-FS),这是Facebook干草堆纸的实现.

Seaweed-FS非常灵活,适用于基础知识.它的创建是为了存储数十亿张图像并快速提供.