怎么存储千万级别的图片文件, 在保证尽可能节省空间的前提下,还能方便读写

[xchaoinfo]

之前的图片都是一个个小文件放在文件夹中, 这样的问题是, 需要的存储空间比较大, 图片迁移也不方便, 而且对 I/O 的消耗非常大. 目前考虑使用数据库来存储, 方案有 lmdb sqlite 请问各位 V 友, 有其他好的方案吗? 能支持多线程读写最好.

[cz5424]

楼主换个 ssd 吧，提高 io，完事

[wangyzj]

ceph，hdfs

[mosliu]

不建议存 db
hdfs 存海量小文件也不太合适。
感觉 ceph fastdfs 之类的好点
或者 minio

[GrayXu]

强力推荐 ceph

[yuyuko]

@stgmsa 你们有对存储做优化吗？

[msg7086]

@ping2 ext4 小文件本来就没有太大优势，不如直接上 reiserfs 了。

[4linuxfun]

为啥没人推荐 fastdfs 了？我感觉够轻量。以前用 hdfs 存小图片，内存占用比较大，服务重启恢复时间长，自从用了 fastdfs，在也不用担心内存被吃爆、服务重启慢问题了。

[yty2012g]

@jackrelative #8 我居然有幸在工作的时候见过用 blob 类型把图片存 DB 的

[venster]

@yty2012g 以前公司的 OA 系统，所有的附件都直接存数据库，接手维护时简直疯了。

[wbrobot]

唉，凸显年龄了，豆瓣以前有解决方案叫 beansdb 类似 file 的 memcache，后面好像没人维护根据 leveldb 改写了？后面没接着用不知道

[wbrobot]

@wbrobot 看了一下，没错，他们用 go 改写了一版 叫 gobeansdb https://github.com/douban/gobeansdb

[ohao]

我有一个图床,量是亿级规模了, 应该算有发言权的

这个问题还是取决于你的规划
比如目前规模,每天的数据增长量,未来一个周期的数据量
以及是热数据还是冷数据
你使用数据库存储就是下下策了

你这种最推荐的是组存储集群 1 源数据+1 副本实现容灾
集群的存储系统有很多 像 Ceph , GlusterFS 这些都可以

然后就是软件 , 可以使用
FastDFS + NGINX
taobao 开源的 TFS + NGINX
等等 都开源

NGINX+imglib 类的库, 可以实现图片常见的操作, 比如改变大小,加水印,翻转 黑白 切割等等操作
这个处理完成后给 CDN 缓存服务器,意味着后端只需要处理一次图片
处理完成后请求都在缓存服务器中 不在耗后端性能
当出现性能请求突发, 需要做的就是加 CDN 缓存服务器提高吞吐能力

如果考虑成本单机存储也可以
硬盘使用 SATA 的 8 块 16 块 组 HW 容灾, 文件系统使用 XFS, (XFS 对小文件优化性能有明显的提升)
在选择前面说的软件搭配

[ming7435]

我们目前存在 mongodb 中的，还是单实例，目前已经存储有 3000+kw 图片

[lenqu]

我个人认为 Hbase 不错，之前当文件数据库使

[swulling]

小文件存储你可以理解为 kv，单机推荐用 rocksdb

[jones2000]

@ohao 对于机器老化需要更替新机器，一般是如果操作的。 比如公司要求 2-3 年需要把老的机器淘汰掉替换成新的机器和新的硬盘。

[stgmsa]

@yuyuko 没有，meta 和 blob 一起存的。如果一定要问有优化么？那就是 后来上传的图片 key 和 meta 都在 ES 里存了一份。
规模
存储 22* 8T * 400 台 * 2 机房
前端机 40 台 E5-2630v2 +128G，（其实从负载看 20 台就足够了）
缓存 4 * DC S3510 600 G * 12 台

[shicheng1993]

可以考虑 swift 对象存储

[hallDrawnel]

B 站 CTO 写过一个小文件 FS，忘记叫什么了，就是专门用来存各种小图片的。

[yuyuko]

@stgmsa 我们要做冷数据引擎，针对 hdd smr 做优化来降本。。。以为你们这个量会做优化的。。。你们不做优化的话，成本。。。机架费用就不少吧。。。。