从数据库中选择和编码 base 64 图像时发现缓慢

Question

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

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

encodeURIComponent($scope.image)

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

decodeURIComponent($scope.image) 

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

工作正常，但花费了我预期的时间。因此，图像的尺寸增大了 33%，而且看起来很鼓。

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

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

Answer 1

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

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

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

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

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

没什么大不了的！

在数据库中保存文件是不好的做法，它应该是你最后的资源。 S3 非常适合许多用例，但对于高使用率来说成本很高，并且本地文件应仅用于 Intranet 和非公共可用应用程序。

在我看来，去 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 万张 jpeg。上传图像时，使用具有无损标志和 80% 质量的 imagick 进行压缩。这将删除不可见的像素并优化您的存储。由于我们的图像从 40x40（缩略图）到 1500x1500（缩放图像）不等，我们平均有 700x700 图像，乘以 130 万张图像，大约 120GB 的存储空间。

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

当事情开始变得缓慢时，您可以聘请 CDN。

这将如何运作？

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

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

这不是一项便宜的服务，但它比云端便宜得多，而且当你需要它时，你可能负担得起。

Answer 2

根据经验，不要将文件保存在数据库中。

mysql手册对此有什么要说的？ http://dev.mysql.com/doc/refman/5.7/en/miscellaneous-optimization-tips.html

使用 Web 服务器，将图像和其他二进制资产存储为文件，使用 存储在数据库中的路径名，而不是文件本身。最多 与数据库内容相比，Web 服务器更擅长缓存文件，因此 使用文件通常更快。 （尽管您必须处理备份和 在这种情况下，您自己的存储问题。）

根本不要将base4编码的文件保存在数据库中

工作正常，但花费了我预期的时间。因此，图像是 尺寸大了 33%，而且看起来很臃肿。

正如您所发现的，编码/解码中不必要的开销 + 额外空间已用完，这意味着额外的数据来回传输。

正如@mike-m 所提到的。 Base64 编码不是一种压缩方法。 @mike-m 发布的链接也回答了为什么使用 Base64 编码 What is base 64 encoding used for?。

简而言之，在将图像存储在 S3 或其他文件系统上之前，通过 base64 编码图像并没有什么收获和损失。

不涉及 base64 的 Gzip 或其他形式的压缩呢？再一次，答案是没有什么可得到的，也没有什么可失去的。例如，我刚刚压缩了一个 1941980 JPEG 图像并保存了 4000 个字节，节省了 0.2%。

原因是图像已经是压缩格式。它们不能被进一步压缩。

当您存储未经压缩的图像时，它们可以直接传送到浏览器和其他客户端，并且可以被缓存。如果它们被压缩（或 base64 编码），则需要由您的应用解压缩。

现代浏览器能够显示嵌入到 HTML 中的 base64 图像，但无法缓存它们，并且数据比需要的大 30% 左右。

这是一个例外吗？

用户可以在那里发布数据和图像，并且都是安全的。

我认为您的意思是用户可以下载属于他或与他共享的图像。这可以通过将文件从网络空间中保存到文件系统中并仅保存数据库中的路径来轻松实现。然后使用fpassthru 将文件发送到客户端（在进行所需的检查之后）

当我增长到 100000 个用户时会怎样

他们如何处理图像文件。在性能问题上，当大 用户参与，它对我来说是接缝，我需要 100000 个文件夹用于 100000 个用户 及其子文件夹。当大量用户浏览同一个根目录时 文件夹，文件系统如何处理每个唯一的文件夹。

使用 CDN 或使用特别适合此的文件系统，例如 BTRFS

数据库具有良好的搜索功能、良好的线程安全连接、良好的会话管理。当涉及大型操作时，这种情况是否会改变

确实如此。通过将有关文件的所有信息及其文件路径保存在数据库中来充分利用它。然后将文件本身保存在文件系统中。两全其美。

Answer 3

我建议你继续使用 base64 字符串，你可以使用 LZ 字符串压缩技术来减小字符串大小。我一直在使用，效果很好。

我不知道我如何接近您的问题，但希望这会对您有所帮助。 这里是 LZ 压缩技术：https://github.com/pieroxy/lz-string/