MySQL - Base64 与 BLOB
MySQL - Base64 vs BLOB
为了简单起见，假设我正在开发一个像 Instagram 这样的移动应用程序。用户可以从服务器下载图片，也可以上传自己的图片。目前，服务器将所有图像（实际上，只是小缩略图）作为 BLOB 存储在 MySQL 数据库中。似乎最常见的传输图像的方式是使用Base64编码，这让我有两个选择：
- 服务器将所有图像存储为 BLOB。上传图片，客户端将其编码成Base64字符串，然后发送给服务器。服务器将图像 BACK 解码为二进制格式，并将其作为 BLOB 存储在数据库中。当客户端请求图片时，服务器将图片重新编码为Base64字符串并发送给客户端，客户端再将其解码回二进制显示。
- 服务器将所有图像存储为 Base64 字符串。要上传图片，客户端将其编码为 Base64 字符串并将其发送到服务器。服务器不进行编码或解码，只是将字符串存储在数据库中。客户端请求图片时，将Base64字符串返回给客户端，客户端解码后显示。
显然，选项 #1 需要在服务器上进行更多处理，因为每个请求的图像必须 encoded/decoded。这让我倾向于选项 #2，但一些研究表明，将 Base64 字符串存储在 MySQL 中比将图像直接存储为 BLOB 效率低得多，通常不鼓励这样做。
我当然不是第一个遇到这种情况的人，所以有人对完成这项工作的最佳方法有什么建议吗？
为什么要对网络上的图像进行 base64 编码？我认为你是从一个错误的假设开始的。
JSON 假定为 utf8，因此与图像不兼容，除非它们以某种方式编码。
Base64 的体积几乎是二进制 (BLOB) 的 8/6 倍。有人可能会争辩说它很容易负担得起。 3000 bytes 变成大约 4000 bytes.
每个人都应该能够接受任意的 8 位代码，但不是每个人都能接受。 Base-64 可能是无需处理 8 位数据的最简单且总体上最好的折衷方案。
因为这些是 "small"，我会将它们存储在 table 中，而不是文件中。但是，我会在需要时通过适当的 id 将它们存储在单独的 table 和 JOIN 中。这允许不需要图像的查询 运行 更快，因为它们不会跨过 BLOB。
从技术上讲，TEXT CHARACTER SET ascii COLLATE ascii_bin 可以，但 BLOB 更清楚地表明该列中实际上没有任何可用的文本。
我不明白为什么数据库服务器不应该始终以其本机形式保存二进制数据。因此，使用 BLOB。
（但即使你确实将数据存储在 Base64 字符串中，也不必担心 encoding/decoding 性能，因为 IO 的影响会更显着。）
我不明白为什么客户端应该以 base64 格式发送数据。为什么不 "stream" 使用简单的 HTTP 调用呢？
为了简单起见，假设我正在开发一个像 Instagram 这样的移动应用程序。用户可以从服务器下载图片，也可以上传自己的图片。目前，服务器将所有图像（实际上，只是小缩略图）作为 BLOB 存储在 MySQL 数据库中。似乎最常见的传输图像的方式是使用Base64编码，这让我有两个选择：
- 服务器将所有图像存储为 BLOB。上传图片，客户端将其编码成Base64字符串，然后发送给服务器。服务器将图像 BACK 解码为二进制格式，并将其作为 BLOB 存储在数据库中。当客户端请求图片时，服务器将图片重新编码为Base64字符串并发送给客户端，客户端再将其解码回二进制显示。
- 服务器将所有图像存储为 Base64 字符串。要上传图片，客户端将其编码为 Base64 字符串并将其发送到服务器。服务器不进行编码或解码，只是将字符串存储在数据库中。客户端请求图片时，将Base64字符串返回给客户端，客户端解码后显示。
显然，选项 #1 需要在服务器上进行更多处理，因为每个请求的图像必须 encoded/decoded。这让我倾向于选项 #2，但一些研究表明，将 Base64 字符串存储在 MySQL 中比将图像直接存储为 BLOB 效率低得多，通常不鼓励这样做。
我当然不是第一个遇到这种情况的人，所以有人对完成这项工作的最佳方法有什么建议吗？
为什么要对网络上的图像进行 base64 编码？我认为你是从一个错误的假设开始的。
JSON 假定为 utf8，因此与图像不兼容，除非它们以某种方式编码。
Base64 的体积几乎是二进制 (BLOB) 的 8/6 倍。有人可能会争辩说它很容易负担得起。 3000 bytes 变成大约 4000 bytes.
每个人都应该能够接受任意的 8 位代码，但不是每个人都能接受。 Base-64 可能是无需处理 8 位数据的最简单且总体上最好的折衷方案。
因为这些是 "small"，我会将它们存储在 table 中，而不是文件中。但是，我会在需要时通过适当的 id 将它们存储在单独的 table 和 JOIN 中。这允许不需要图像的查询 运行 更快，因为它们不会跨过 BLOB。
从技术上讲，TEXT CHARACTER SET ascii COLLATE ascii_bin 可以，但 BLOB 更清楚地表明该列中实际上没有任何可用的文本。
我不明白为什么数据库服务器不应该始终以其本机形式保存二进制数据。因此，使用 BLOB。 （但即使你确实将数据存储在 Base64 字符串中，也不必担心 encoding/decoding 性能，因为 IO 的影响会更显着。）
我不明白为什么客户端应该以 base64 格式发送数据。为什么不 "stream" 使用简单的 HTTP 调用呢？