刚刚上的独立的图片服务器，目前总共图片数量在25000左右，加上每张图片的10几个缩略图，大概有30w的图片数量，全部存在了一个文件夹中，用nginx作为web server，后面用tomcat处理动态图片的请求。
现在要上一批新图片，总量在50w，加上缩略图，文件数量在百万到千万级别，如何更好的设计文件结构，能够使查找的效率最优化？
建议使用hash tree 存储
如果直接存储在文件系统，MD5做hash,3级目录完全可以满足图片日后图片增长需要，也可以避免图片重复存储的问题。用md5值来索引查找。
/ab/cd/ef/abcd....xx.jpg
存储容量可以达到36^6*1024个文件
图片服务器只要保存原图既可以了，缩略图、水印等可以根据请求用ImageMagick生成。这样可以分布到别的服务器，方便迁移等
/800x600/ab/cd/ef/abcd....xx.jpg
/400x300/ab/cd/ef/abcd....xx.jpg
......
以前我做过一个类似的项目，也是nginx做web server；tomcat做动态请求
我的文件组织分了三层
url这样：
http://example.com/年/月/[00-FF]随机码_widthxheight.jpeg
目录结构是：
年份
|_ 月份
|_ 00
|_ 01
|_ ...
|_ FF一张图片上传，00-FF的目录哈希的
另外，有一个要注意的是，同一个文件夹下的文件个数不宜太多，否则读取文件的速度会变慢。
很早以前，Linux Ext2还是Ext3我忘了，测试 单目录 3000 文件是个瓶颈
传统方案都有一些瓶颈， 比如说单节点数据不平衡得问题， 大家认为hash 就没有问题，其实hash 也是有问题得， 热点均衡， 数据规模扩展（普通hash 对于扩展性是非常差得， 所以又引入了一致性hash 的方案， 而一致性hash 也不是最终方案，还是有迁徙得问题 只是不太严重而已） 还引入了引用计数这样得更多问题。 相对而言 云存储方案 比较好， 说白了云存储方案就是一个 比较好得 动态扩展方案， 也有用一致性hash 完成得， 这些方案比传统得目录方式 优势还是很明显。 第一 节点可扩展，第二 专业 专门解决 想到得问题。 所以建议使用云方案。 云方案 就是张小泉，只做那一样 肯定比你专业。
如果是本地存储建议用raiserfs类型，如果是量大，建议用分布式文件存储，或者又拍。
可以考虑分布式文件系统。
据我自己业务的经验来说，图片的重复率是很高的，如果针对图片的比如md5做key的话可以排除掉一部分图片，排重后可以节省存储空间，也可以加快查找速度。如何高效地查找图片是一个存储的问题，存储的架构做好了才会高效，对落地的存储做分布存储是很有必要的，而且要解决存储的单点问题。对热点图片做cache也能加快访问减少后端访问压力。如何做分布存储就涉及比较多了我也刚入门，各个公司都有自己的一套方案，可以参考GFS的解决方案。