一尘不染

从数据库选择base 64图像并进行编码时发现速度慢

mysql

我在离子框架中工作。当前正在设计带有文本和图像的帖子页面。用户可以在那里发布数据和图像,并且所有信息都是安全的。

因此,我使用base 64编码并将图像保存在数据库中。

encodeURIComponent($scope.image)

每当用户请求时,我都会从表中选择行,并将其与文本一起显示并进行解码。

decodeURIComponent($scope.image)

HTML "data:image/jpeg;base64,_______"转换。

效果很好,但是花了我预期的时间。因此,图像的尺寸要大33%,并且看起来整体比较笨拙。

然后,我决定继续进行科尔多瓦的文件上传插件。但是我意识到,以这种方式维护文件是非常危险的。我也尝试将二进制数据保存到数据库中。但是失败了。

没有base64数据的文本选择大大减少了时间。如果可以在选择其他列并显示后,在另一个http呼叫中单独选择图像。处理安全图像是否正确?


阅读 280

收藏
2020-05-17

共1个答案

一尘不染

由于只是个人文件,您可以将它们存储在S3中。

为了确保文件上传安全,只需在上传之前检查文件的mime类型,即可选择所需的存储空间。

http://php.net/manual/zh/function.mime-content-
type.php

只需对上传的文件进行快速检查:

$mime = mime_content_type($file_path);
if($mime == 'image/jpeg') return true;

没什么大不了的!

将文件保留在数据库中是不好的做法,这应该是您的最后资源。S3非常适合许多用例,但对于高使用率而言则很昂贵,并且本地文件应仅用于Intranet和非公共可用的应用程序。

我认为,请转到S3。

亚马逊的sdk易于使用,您可以免费使用1GB的存储空间进行测试。您也可以使用自己的服务器,只是将其保留在数据库之外。

在文件系统上存储图像的解决方案

假设您有100.000个用户,每个用户都有10张图片。您如何处理本地存储? 问题:
成千上万个映像后,Linux文件系统中断,因此您应该使文件结构避免这种情况

解决方案: 将文件夹名称设置为“ abs(userID / 1000)* 1000” / userID

这样,当您的用户ID为989787时,其图像将存储在文件夹989000/989787 / img1.jpeg 989000/989787 /
img2.jpeg 989000/989787 / img3.jpeg上

这样就可以为一百万个用户存储图像而不会破坏UNIX文件系统。

存储大小如何?

上个月,我不得不为自己从事的电子商务压缩130万jpeg。上传图像时,请使用具有无损标记和80%质量的imagick进行压缩。这将消除不可见的像素并优化存储。由于我们的图片从40x40(缩略图)到1500x1500(缩放图片)不等,因此我们平均获得700x700的图片,是130万张图片的总和,约占120GB的存储空间。

是的,可以将它们全部存储在文件系统中。

当事情开始变慢时,您可以租用CDN。

那将如何工作?

CDN位于映像服务器的前面,每当CDN被要求提供文件时,如果在其存储中找不到文件(缓存未命中),它将从映像服务器复制它。稍后,当再次请求CDN
get时,它将从其自己的缓存中传递图像。

这样,无需任何代码即可迁移到CDN映像交付,您所需要做的就是更改站点中的URL并租用CDN,这与S3存储桶的工作原理相同。

它不是一项便宜的服务,但是比cloudfront便宜,而且当您需要它时,您可能可以负担得起。

2020-05-17