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

[xchaoinfo]

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

[594duck]

@hakono 兄弟说话到位的，现在 V2EX 上一堆年轻的战狼程序 员。 你的思路是非常对的。七牛啥的都是按这个思路做的。

[aliyun75]

@xchaoinfo 推荐你阿里云的低频访问类型的 OSS，符合你要求的高读写和多线程读写，我这里还能给你提供优惠，有需求联系我 VX:一三一零一二三四五三九

[stgmsa]

@yuyuko 什么 ？ SMR ？ 你确定 ？ 打算用消费级的硬盘吗 ？
是你 还是 你们运维 和采购 拍 奶子做的决定？
不管是谁只要出问题不是你背锅就行。

如果在国内公司写代码，连硬盘选型采购 都要一个程序员推动的话，还是劝尽早解脱（如果你在 Facebook 这种公司做 SWE，当我没说）。
我们现在有成本优化方案。不过是通过不断迁移在用数据，淘汰老数据下架来完成的。目前就在做。

不过说实话，千万级别的图片
100000000(按 1E 算) * 100 （ 100k 一张） / 1000 （到这是 MB ） / 1000 （到这是 GB ） / 1000 （到这是 TB ） = 10 TB...

存储大概就是 2-4 台 1U 的小机机 ？

[stgmsa]

@yuyuko 上面提到的 key 信息入 ES 就是为迁移数据做准备的。
另外作为公共服务，优化存储成本是比较坑爹的事情，业务不像你想的那么配合 那么好推动（当然存储成本甩到业务线这个事就能好办很多）

前端机我接手之前是 160 台，通过替换缓存+k8s 署了一部分 pod 来抗量，干到 40 台 。
然而存储一般不会轻易去优化。一来周期会很长，二来沟通人力成本很高。一般存储上架就是一步到位顶 3 年的量的。

不过从运维角度来讲，如果你采用了不合规的硬件（也包括软件，网络 blablabla ），导致业务受影响了。这个锅可不是一般人能背得起的。轻则开除，重一点 你的直属领导 甚至总监级一起背锅滚蛋。
不让你赔偿损失就不错了（参考下广告展示多少图，你图床高峰期宕机 1 个小时试试？）

之前就有同事因为这个被开过（他还没过试用期呢）。优化成本固然没有错。我也是资瓷的。但是一定不要无底线的优化 （你需要清楚的知道自己到底在做什么，而不是一味地追求好数据 好绩效 而玩火）

[stgmsa]

@yuyuko 上面提到的 ceph glusterfs，mongo，hdfs hbase 公司各个业务线都有使用的场景。
但是…… 不建议从 0 开始就上。

举个例子，openstack 的虚机数据 和 io 都落在了 ceph 集群上，ceph 吃的裸盘，裸盘上面有 cache tier （好像也是 600G 的 dcs3500 3510 sata ssd，没办法，公司买了太多 消化不完），曾经出现过很多次 因为集群里 某块盘挂了 导致 整个虚拟机集群 io hang 住的情况（基础运维能力太渣的话，技术方案再怎么牛逼也不好用）

mongo 早些年间（大概是 2015 年？）出现过业务写的太疯狂 导致一个 mongo 吃掉了一整台物理机的资源 影响其他用户的（现在这种情况应该是没有了）

如果你们的支撑团队牛逼，我想他们会给你一个合理的方案的（比如你们的基础运维团队，在了解到你想用 fs 来搞的时候 会告诉你 XFS 还是 ext4，inode 要不要搞小一点，是走 lvm 还是直接干 ），你的 dba 团队也会根据你的 场景来告诉你 是走 hdfs 还是 走 mongo 就能搞定，还是吃个螃蟹，memorykey + optane 的解决方案。

多问问他们，他们可能是你这个系统后续 要持续打交道的人。。(他们也不想半夜接到你电话爬起来开电脑不是)

[binux]

那么多不推荐用 db 的到头来推荐一个为小文件优化过的 fs 。。。
我说名字就那么重要吗？它是实现成 fs 和还是 db 有区别吗？

[stgmsa]

另外 也不是推荐跟我们一样 用 cassandra 。
ceph glusterfs 普通的 fs，seaweed 的实现方案产品， 甚至 mongo，mysql 分个库 分个表
都能实现你的需求。
主要是 …… 这些东西 哪个你们最熟 出问题了能玩的转

[hankai17]

@stgmsa 咨询一下有用过 ats 吗?

[vavava]

BerkeleyDB，然而维护可能麻烦些，不做频繁删除的话还好

[stgmsa]

@hankai17 apache 那个缓存么？ 没用过 ……

[newmlp]

相信文件系统就是干这个的，存数据库里纯粹脱了裤子放屁，还有合并成大文件方法也是一样，本质上文件系统也是 offset 磁盘上的物理磁道，

[P0P]

@newmlp 文件系统维护小文件 metadata 开销很大的，自己合并成大文件，然后记录 offset 的话相当于把 metadata 的维护压力放到用户端来做了

[pythonee]

# 好场景

如果你能说明更加具体的业务场景，读写逻辑，估计 v 站的大神能给出更具体的方案

[yuyuko]

@stgmsa dropbox 就是用的 smr，我们这里已经准备开始搞了，国内三家电商之一。。。。