1.文件系统一定是要使用的，为了管理数千万的图片，必须进行目录分层，因为一个目录下不可能存放太多的文件，前期的目录规划要考虑后期的扩展，

    还有图片分布均匀，这样做下来，往往目录的深度会达到5层甚至7层

    2.数据迁移，备份怎么做？高级的NAS存储，有自己的卷复制，但这个粒度太粗，如果要细分到底层或中间层，会有点力不从心，对于这种大数据量的

    小文件拷贝，PC也是非常吃力

    3.每一个图片的访问，基本会做5-7次的目录跳转，转换到磁盘，也可能有10次物理IO了，在并发量上来的时候，磁盘会是个瓶颈，当然，分布式是个方向

    (

    key number not null,

    pic blob

    );

    VALUE就是图片内容，用blob来保存

    访问一个图片的方式就是：

    获取图片名称 数据key

    走key上的索引，定位到记录表记录

    根据表记录，定位到图片的blob，并读取

    1.单个图片的访问路径缩短，数字索引比较小，分区做的好的话可能小到两层，从索引到表，到blob段，大概是4-5跳

    并且KEY是区分度非常高的数据类型，在索引每层的横向检索中，不会超过1个数据块，而文件目录结构中，子目录繁多，

    要遍历这层的inode后，才知道具体跳转的下层位置

    2.备份方式比较灵活，可以基于整个数据库，或者单独的表，数据的迁移，删除，都是基于表级别的，比较直观，方便

    3.可以在数据库层面，考虑图片的水平拆分，垂直拆分，分表，分库，都不错

    4.数据库的复制技术可以派上用场，读写分离

    大致画了一个草图，当然在WEB与picdb间应该还有层cache的

    这个方法是YY出来的，可能很多地方不成熟，但SY强身，YY强国，没有想法，哪来的动力？欢迎各位专业人士拍砖