一、常规图片存储策略
常规的一般400G以下的图片存储可以采用比较传统的分目录的形式
例如目录层级为 年份/行业属性/月份/日期/用户属性
有几个比较重要的原则就是
1、单个目录下的文件个数不要超过2000个,多了寻址较慢,你在linux下ls就能看到数量太多的时候的效果了
2、目录层级结构不要太深,这样服务器处理寻址较慢
二、海量图片存储策略
1、核心难点
(1)海量的意思就是图片的数量级别是上亿--光是我们建立索引就玩不转,没那么牛的库存储
(2)图片总大小是按照T计算的--单个节点肯定支持不了
(3)图片访问很容易有长尾效应--就是没有所谓的热点
2、解决方案
(1)、存储方案
采用分布式随即的方式将一些小文件存放到分布式集群环境中,用hash的方式来记录位置(一般是先hash,然后确认存储位置)。将位置直接作为文件名称
计算哈希的常见方法: hash(key)%n =》大致的物理位置
分布式存储常见方案:hdfs,tfs....
(2)、访问方案(假设我们用apache)
硬访问
直接让apache根据文件名字找到指定文件存放位置,读取文件流
软访问:
直接用apache的rewrite这个功能,将文件读取
小图片存储:
数据库:
1.数据读取稳定,写入方便。
2.输出到页面成功率高,基本不会有文件损坏只能读取一部分的情况。
3.不方便分布及同步。
4.重复数据无法剔除。
5.无法利用浏览器多个域名多线程特性,性能会成为问题。
6.修改量大会使得数据库碎片上升,性能下降。
文件系统:
1.需要有算法保持目录文件中的数量。存储要散列,一个目录下不能放太多文件。
2.可以使用文件系统缓存和Squid等缓存。
4.可以给相同的图片用硬链接减少重复文件数目。
5.易分布,也可根据需要同步部分数据。
6.解决方案多。
7.可能因硬件或网络异常而造成的图片文件损坏。
8.对文件系统或存储方案有一定的要求