位图和图像大小答案

【问题标题】：Bitmap and image size [closed]位图和图像大小
【发布时间】：2020-09-13 15:50:12
【问题描述】：

我有两种方法可以在我的数据库中存储图像。

{
name: "picture1",
ImageBitmap: "25fd73dye80942qfo2579_6306"
}

或者 2. 将它们存储在服务器上的某个位置并将 URL 保存在表中：

{
name: "picture1",
ImageBitmap: "https://myserver.com/imagefolder/picture1.png"
}

在第一种情况下，假设我要检索 100 行，每张图片大约 1mb。

如果我向这个端点发出一个 http 请求，它会返回 100mb 的数据吗？还是位图大小不等于图片大小？

【问题讨论】：

【解决方案1】：

看起来您数据库中的“位图”是 Base64 编码的。但这是一个猜测。如果使用 BLOB objects in place of TEXT 对象，则不必使用 Base64。

很难从您的问题中看出，在第一种情况下，单个请求是返回所有图像还是每个请求仅返回一个图像。但话虽如此，您在生产中会遇到大小约为 0.1 GiB 的单个响应的问题。不是一个好主意。使用更多请求，每个请求返回的结果要小得多。

恕我直言，您的第一个方案是一个糟糕的想法。为什么？

每次 Web 浏览器或其他客户端需要图像时，您的 MySQL 服务器都必须将大量数据移动到您的 REST 服务器，而 REST 服务器必须将其传递给您的客户端。那是很大的负担。数据库服务器是扩展系统中的稀缺资源。您不想让他们承担向客户端提供图像所需的所有 SSD 和网络 IO。
当客户端从服务器上的目录中检索对象时，它会使用基于文件的 Web 服务器。当该 Web 服务器（apache、nginx、lighttpd）收到请求时，它会将文件映射到 RAM 中并将其发送出去。这种风格的服务器已经开发了 25 年了：它们高效、安全、易于配置和监控。
以这种方式检索对象可以扩展以利用全球内容交付网络真正轻松。（Cloudflare？Amazon Cloudfront？如果你有钱，甚至是 Akamai。）
您的图像对象（从基于文件的 Web 服务器提供）可以利用 http 协议的缓存方面，因此它们不必反复提供给同一个客户端，或提供给同一个代理的事件。它们是静态的：它们不会在不更改名称的情况下更改。
与充满 BLOB 的大型数据库表相比，充满文件的目录更更容易备份和恢复。

【讨论】：

【解决方案2】：

直接回答您的问题：

您的位图数据是 base64 编码的。 base64 的工作方式是将三个 8 位二进制字节编码为四个 6 位 base64 数字，因此这些数字可以用可打印的 ASCII 字符表示。

这意味着 base64 编码数据的大小正好是等效二进制数据大小的 4/3。它比它编码的二进制数据大。

【讨论】：