使用数据库存放图片

图片是网站上很重要的资源，用户发布的产品图片，用户的logo，AV男，兽兽女，犀利哥等等等等，一个稍具规模的网站，图片的数量可能是千万级，这种资源的特点就是文件小，数量大，每个文件在几字节到几K不等，所以针对图片的访问，基本是非常离散的IO，考验的是系统的磁盘并发和CPU处理能力
一般网站，图片都是存放专门的图片服务器，可集中也可以分布式，比如有条件的可以购买昂贵的NAS存储，由主机拖着，以NFS或者HTTP的方式，供前面的应用
访问，或者使用多台廉价PC，图片分布打散到每个机器，前台应用解决图片存取和访问策略，以便充分利用所有资源，在应用与图片服务器中间还可能加一层cache，来缓冲前台的访问压力
上面所说的方法，弊端是有很多的
1.文件系统一定是要使用的，为了管理数千万的图片，必须进行目录分层，因为一个目录下不可能存放太多的文件，前期的目录规划要考虑后期的扩展，
还有图片分布均匀，这样做下来，往往目录的深度会达到5层甚至7层
2.数据迁移，备份怎么做？高级的NAS存储，有自己的卷复制，但这个粒度太粗，如果要细分到底层或中间层，会有点力不从心，对于这种大数据量的
小文件拷贝，PC也是非常吃力
3.每一个图片的访问，基本会做5-7次的目录跳转，转换到磁盘，也可能有10次物理IO了，在并发量上来的时候，磁盘会是个瓶颈，当然，分布式是个方向
这里想到了另外一种方法，利用数据库来存放图片，存储的方式就是现在最流行的key-value
create table mypic
(
key number not null,
pic blob
);
create index ind_picid on mypic(key);
key是图片名称，事先最好统一规划一下，使用number数字来命名，并针对key建立索引
VALUE就是图片内容，用blob来保存
访问一个图片的方式就是：
获取图片名称  数据key
走key上的索引，定位到记录表记录
根据表记录，定位到图片的blob，并读取
这个方法的优点：
1.单个图片的访问路径缩短，数字索引比较小，分区做的好的话可能小到两层，从索引到表，到blob段，大概是4-5跳
并且KEY是区分度非常高的数据类型，在索引每层的横向检索中，不会超过1个数据块，而文件目录结构中，子目录繁多，
要遍历这层的inode后，才知道具体跳转的下层位置
2.备份方式比较灵活，可以基于整个数据库，或者单独的表，数据的迁移，删除，都是基于表级别的，比较直观，方便
3.可以在数据库层面，考虑图片的水平拆分，垂直拆分，分表，分库，都不错
4.数据库的复制技术可以派上用场，读写分离
这里数据库完全是当成一个KEY-VALUE的存储在用，我们可以考虑将一些廉价的PC堆在一起，做成一个picdb的群集，

大致画了一个草图，当然在WEB与picdb间应该还有层cache的
这个方法是YY出来的，可能很多地方不成熟，但SY强身，YY强国，没有想法，哪来的动力？欢迎各位专业人士拍砖.