关于图片或者文件在数据库的存储方式归纳

据我了解,互联网环境中,大访问量,数据库速度和性能方面很重要。一般在数据库存储图片的做法比较少,更多的是将图片路径存储在数据库中,展示图片的时候只需要连接磁盘路径把图片载入进来即可。因为图片是属于大字段。一张图片可能1m到几m。

有个原则:图片尽量不要存储在数据库中(是指不要二进制形式保存到字段,而只保存图片的路径)。这样的大字段数据会加重数据库的负担,拖慢数据库。在大并发访问的情况下很重要。这是一个经验。去看看dba对数据库性能调优方面的分析都能得到这个答案的:就是图片不要存储在数据库中。

二、数据库中保存图片路径

一般是这样子的:

按照年月日生成路径。具体是按照年月日还是按照年月去生成路径,根据自己需要(不一定是按照日期去生成)。

理解为什么要分散到多个文件夹中去才是关键,涉及到一个原理就明白了:

操作系统对单个目录的文件数量是有限制的。当文件数量很多的时候。从目录中获取文件的速度就会越来越慢。所以为了保持速度,才要按照固定规则去分散到多个目录中去。

图片分散到磁盘路径中去。数据库字段中保存的是类似于这样子的”images/2012/09/25/ 1343287394783.jpg”

原来上传的图片文件名称会重新命名保存,比如按照时间戳来生成,1343287394783. jpg。这样子是为了避免文件名重复,多个人往同一个目录上传图片的时候会出现。

反正用什么样的规则命名图片,只要做到图片名称的唯一性即可。

比如网站的并发访问量大,目录的生成分得月细越好。比如精确到小时,一个小时都可以是一个文件夹。同时0.001秒有两个用户同时在上传图片(因为那么就会往同一个小时文件夹里面存图片)。因为时间戳是精确到秒的。为了做到图片名称唯一性而不至于覆盖,生成可以在在时间戳后面继续加毫秒微秒等。总结的规律是,并发访问量越大。就越精确就好了。

我现在还没碰到需要这么精细的。概率比较少。

有个方面总结一下:为什么保存的磁盘路径,是”images/2012/09/25/1343287394783.jpg”,而不是” /images/2012/09/25/ 1343287394783.jpg”(最前面带有斜杠)

我的理解:

连那个斜杠都不要。这里也是做到方便以后系统扩展。

在页面中需要取出图片路径展示图片的时候,如果是相对路径,则可以使用”./”+”images/2012/09/25/1343287394783.jpg”进行组装。

如果需要单独的域名(比如做cdn加速的时候)域名,img1.xxx.com,img2.xxx.com这样的域名,

直接组装 “http://img1.xxx.com/”+”images/2012/09/25/1343287394783.jpg”

当然数据库是可以在前面加斜杠/保存起来,/images/2012/09/25/ 1343287394783.jpg

其实不方便统一。比如相对路径载入图片的时候,则是”.”+” /images/2012/09/25/ 1343287394783.jpg”

可能我还没体会到坏处,以后会遇到问题的。不过,遵循惯例不加斜杠” images/2012/09/25/ 1343287394783.jpg”就对了。

涉及到一个新问题:为什么大部分系统都不会域名保存进去,像这样子http://www.xxx.com/images/2012/09/25/1343287394783.jpg保存到数据库中

曾经与一个上海的网友聊天,他也是习惯不会把域名保存数据库中过去。但当时我们两聊的时候,他对”域名保存进去的做法”与”不保存域名进去”也没有一个明确利弊。他就觉得,没有什么明显的区别啊。

了解的知识越多,越有利于我们做决定。可能就是一个”感觉区别不是很大”的影响下,去做一个决定,反而对后面是比较大的影响的。至少是增加自己的工作量了。

其实把域名保存进去,也不是什么滔天大罪的事情。但凡是经验丰富的开发人员都不会这样子做。这是一个经验积累出来的,所以上海那个网友也对此并没有明显的概念很正常,他说他不知道cdn方面的(当然觉得存个域名进去没什么大不了的)。需要了解cdn知识,什么情况下会用到cdn知识。

虽然是做开发人员,不需要关注运维和服务器之类的知识。不过了解一些就有利于理解了。

这里涉及到cdn加速。

原文地址:https://www.cnblogs.com/jerrypro/p/6423371.html