从数据库中选择和编码 base 64 图像时发现缓慢 [英] Slowness found when base 64 image select and encode from database

问题描述

我在离子框架中工作.目前正在设计一个带有文本和图像的帖子页面.用户可以在那里发布数据和图像，一切都是安全的.

I am working in ionic framework. Currently designing a posts page with text and images. User can post there data and image and all are secure.

所以，我使用 base 64 编码并将图像保存在数据库中.

So, i use base 64 encoding and save the image in database.

encodeURIComponent($scope.image)

每次用户请求时，我都会从表中选择行并将它们与文本一起显示并解码.

Each time when user request, i select rows from table and display them along with text and decode them.

decodeURIComponent($scope.image) 

使用 HTML "data:image/jpeg;base64,_______" 转换.

with HTML "data:image/jpeg;base64,_______" conversion.

工作正常，但花费的时间超出了我的预期.因此，图像尺寸增大了 33%，并且看起来完全凸出.

Works fine, but take so much time that i expected. Hence, image are 33% bigger size, and totally looks bulgy.

然后我决定继续使用cordova的文件上传插件.但我意识到，以这种方式维护文件风险很大并且很复杂.我也尝试将二进制数据保存到数据库中.但是失败了.

Then i decide to move on file upload plugin of cordova. But i realize, maintain file in this way is so much risk and complected. I also try to save binary data into database. But failed.

没有 base64 数据的文本选择会大大减少时间.如果可以在另一个 http 调用中单独选择图像，则在选择其他列并显示后.这是处理安全图像的正确机制吗?

Text selecting without base64 data are dramatically reduce time. If it is possible to select image individually in another http call, after selecting other column and display. Is it a right mechanism to handle secure images?

推荐答案

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

Since it's just personal files, your could store them in S3.

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

In order to be safe about file uploads, just check the file's mime type before uploading for whatever storage you choose.

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

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

just run a quick check on the uploaded file:

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

没什么大不了的！

在数据库中保存文件是不好的做法，它应该是你最后的资源.S3 适用于许多用例，但它对于高使用率来说很昂贵，并且本地文件应该仅用于内部网和非公开可用的应用程序.

keeping files on the database is bad practise, it should be your last resource. S3 is great for many use cases, but it's expensive for high usages and local files should be used only for intranets and non-public available apps.

在我看来，去 S3.

亚马逊的 sdk 易于使用，您可以获得 1GB 的免费存储空间用于测试.你也可以使用你自己的服务器，只要把它放在你的数据库之外.

Amazon's sdk is easy to use and you get a 1gb free storage for testing. You could also use your own server, just keep it out of your database.

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

假设您有 100.000 个用户，每个用户都有 10 张照片.您如何处理将其存储在本地?问题: Linux 文件系统在几十万个图像后崩溃，因此您应该使文件结构避免这种情况

Let's say you have 100.000 users and each one of them has 10 pics. How do you handle storing it locally? Problem: Linux filesystem breaks after a few dozens of thousands images, therefore you should make the file structure avoid that

解决方案:使文件夹名称为'abs(userID/1000)*1000'/userID

Solution: Make the folder name be 'abs(userID/1000)*1000'/userID

这样，当您拥有 id 为 989787 的用户时，它的图像将存储在文件夹中989000/989787/img1.jpeg989000/989787/img2.jpeg989000/989787/img3.jpeg

That way when you have the user with id 989787 it's images will be stored on the folder 989000/989787/img1.jpeg 989000/989787/img2.jpeg 989000/989787/img3.jpeg

这就是一种为一百万用户存储图像且不会破坏 unix 文件系统的方法.

and there you have it, a way of storing images for a million users that doesn't break the unix filesystem.

存储空间大小如何?

上个月，我不得不为我从事的电子商务压缩 130 万个 jpeg.上传图像时，使用带有无损标志和 80% 质量的 imagick 进行压缩.这将删除不可见的像素并优化您的存储.由于我们的图像从 40x40(缩略图)到 1500x1500(缩放图像)不等，我们平均有 700x700 图像，乘以 130 万张图像，填充了大约 120GB 的存储空间.

Last month I had to compress a 1.3 million jpegs for the e-commerce I work on. When uploading images, compress using imagick with lossless flags and 80% quality. That will remove the invisible pixels and optimize your storage. Since our images vary from 40x40 (thumbnails) to 1500x1500 (zoom images) we have an average of 700x700 images, times 1.3 million images which filled around 120GB of storage.

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

So yeah, it's possible to store it all on your filesystem.

当事情开始变慢时，您可以聘请 CDN.

这将如何运作?

CDN 位于您的图像服务器前面，每当 CDN 请求文件时，如果在其存储中找不到它(缓存未命中)，它将从您的图像服务器复制它.稍后，当再次请求 CDN get 时，它将从自己的缓存中传送图像.

The CDN sits in front of your image server, whenever the CDN is requested for a file, if it doesn't find it in it's storage (cache miss) it will copy it from your image server. Later, when the CDN get's requested again, it will deliver the image from it's own cache.

这种方式无需代码即可迁移到 CDN 图像交付，您只需更改站点中的 url 并租用 CDN，这同样适用于 S3 存储桶.

This way no code is needed to migrate to a CDN image deliver, all you will need to do is change the urls in your site and hire a CDN, the same works for a S3 bucket.

这不是一项便宜的服务，但比 cloudfront 便宜很多，当您需要它时，您可能负担得起.

It's not a cheap service, but it's waaaaay cheaper then cloudfront and when you get to the point of needing it, you can probably afford it.

这篇关于从数据库中选择和编码 base 64 图像时发现缓慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！