正在开发一个图片管理网站（类似www.flickr.com图片管理网站），遇到了一些问题，希望大家多多指教
1.如果想提高图片存取效率，是不是该用图片压缩以提高性能？
2.图片直接放在数据库中好（二进制），还是在数据库存路径，文件系统存对应图片好？
3.还有这种网站一般那些东西要进行缓存？类似SNS网站
谢谢大家！
问题补充
1.另搞一个图片服务器，专门用于存储和读取图片
2.图片上传时，生成缩略图
3.如果只是纯粹的图片的访问，可以考虑不经过数据库，直接算法取文件
4.是否用数据库来存储图片文件流，做地图的好像都是存储的图片数据流，不过他们应该有个好算法，也可能是从安全方面上考虑才这样，个人觉得一般站点的话，还是存路径要好点。
感觉这是架构师的工作哦。 一点都不明白，几乎难作。
那得看你服务器的容量和性能了，别人TX每天上传上千万张的图片都行。
首先我是 菜鸟.我抛出我的不成熟的观念.
考虑到读取图片需要耗费比较大的资源,可采用代理模式.使真正的对象只在真正需要的时候被创建.
而这个代理的对象的作用是代替真实的对象接受请求.
接受到请求后,可做一定的处理,比如说显示"正在加载图片..."
代理对象的另一个作用是在恰当的时候加载真实的对象.
图片压缩是可以考虑的,不过对图片要求较高的就另当别论了. 如果图片不是很重要的,后台没有群集的建议不要保存到数据库.缓存的话就看你的策略了(怎么提高命中率,这个和你的业务有关系了),不过你可以在图片显示上做一点出来,比如先显示小图片,点击了再显示大图片.
1.如果想提高图片存取效率，是不是该用图片压缩以提高性能？
你先要搞清楚瓶颈在哪里！386配光阵列和志强配老硬盘都有不同的选择的。
2.图片直接放在数据库中好（二进制），还是在数据库存路径，文件系统存对应图片好？
对于图片储存，应该使用专用数据库或者专用文件系统，不要用通用数据库。通用数据库相对很浪费。因为图片只需要精确名称对应一块空间。建立简单的b树就可以了。用不着用通用数据库那种复杂的索引。选择带索引的文件系统也是一种不错的选择。
3.还有这种网站一般那些东西要进行缓存？类似SNS网站
这个不应该问别人！
我有个构想，一般图片的存取肯定是读取占操作的大多数，而且不可能每次读取都完整的下载整张图片
是否在图片上传的时候，在图片适当压缩的基础上
同时制作一张同名的缩略图，在读取的仅仅展现缩略图
在真正需要大图的情况下再去读取大图。
加快浏览速度又减少需要大量处理数据的机会
关于是流形式存在数据库，还是存路径，这个个人感觉是存路径比较快点，为什么可能和流与图片的转换有关，个人愚见，等待高手进一步解答
个人感觉，主要瓶颈在缓存上，多在算法上下功夫