当基64图像从数据库中选择和编码时发现的缓慢性

Question

当基64图像从数据库中选择和编码时发现的缓慢性我在离子框架内工作。目前正在设计一个包含文本和图像的帖子页面。用户可以在那里张贴数据和图像，而且都是安全的。因此，我使用base 64编码，并将图像保存在数据库中。encodeURIComponent($scope.image)每次用户请求时，我都会从表中选择行，并与文本一起显示它们，并对它们进行解码。decodeURIComponent($scope.image)用HTML"data:image/jpeg;base64,_______"转换。工作很好，但花了我所期望的那么多时间。因此，图像大33%的大小，完全看上去膨大。然后我决定转到Cordova的文件上传插件上。但我意识到，以这种方式保存文件是很大的风险和复杂性。我还尝试将二进制数据保存到数据库中。但失败了。没有base 64数据的文本选择大大减少了时间。如果可以在另一个http调用中单独选择图像，则在选择其他列并显示之后。它是处理安全图像的正确机制吗？

Answer 1

因为这只是个人文件，所以你可以将它们存储在S3中。

为了确保文件上传的安全性，只需在上传之前检查文件的MIME类型，以确定您所选择的任何存储。

http：/php.net/手册/en/Function.MIME-Content-type.php

只需快速检查上传的文件：

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

别小题大作!

将文件保存在数据库中是不好的做法，它应该是您的最后资源。S3对于许多用例来说都是很棒的，但是对于高使用率来说，它是昂贵的，本地文件应该只用于内部网和不可公开的应用程序。

在我看来，去S3吧。

Amazon的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万个jpegs。上传图像时，使用图像压缩，使用无损标志和80%的质量。这将删除不可见的像素，并优化您的存储。由于我们的图像从40x40(缩略图)到1500x1500(缩放图像)，我们平均有700x700张图像，乘以130万张图像，填充了大约120 GB的存储空间。

所以，是的，可以将其全部存储在您的文件系统中。

当事情开始变慢时，你会雇佣一个CDN。

那该怎么办？

CDN位于您的映像服务器的前面，每当CDN被请求要一个文件时，如果它在它的存储中找不到它(缓存丢失)，它将从您的图像服务器复制它。稍后，当CDN再次被请求时，它将从它自己的缓存中传递图像。

这样就不需要代码迁移到CDN映像传递，您所需要做的就是更改站点中的URL并雇用CDN，这对于S3桶来说是一样的。

这不是一种便宜的服务，但它比CloudFront便宜，当你到需要它的时候，你可能买得起它。