Base64 编码数据 - 数据库或文件系统答案

【问题标题】：Base64 Encoded Data - DB or FilesystemBase64 编码数据 - 数据库或文件系统
【发布时间】：2011-11-21 17:41:23
【问题描述】：

我有一个新程序，它将生成大量 Base64 编码的音频和图像数据。这些数据将通过 HTTP 以 XML 的形式提供，Base64 数据将是内联的。这些文件很可能会突破 20MB 或更高。直接从文件系统提供这些文件会更有效，还是将数据存储在 MySQL 数据库中是否可行？将设置缓存，但总体而言没有必要，因为这些数据可能会在创建和提供后不久被清除。

我知道在大多数情况下，在数据库中存储二进制数据是不受欢迎的，但由于这都是字符数据，我想看看共识是什么。到目前为止，出于效率原因，我倾向于将它们存储在文件系统中，但如果将它们存储在数据库中是可行的，那么管理数据会容易得多。

【问题讨论】：

将原始文件保存在文件系统上并使用base64即时编码。
之所以不赞成将二进制数据存储在DB中的原因不是数据是二进制的，而是它是不可变的，不参与信息逻辑数据库模型。数据的 base64 表示也是如此，因此最好也将其放入单独的存储中，并且数据库应该只维护一个索引。
我倾向于这种逻辑，Kerrek。即时编码可能是可行的，但我可能需要事先生成文件并将其存储在某处。听起来像存储这些数据，无论它是什么形式，都将更适合文件系统。这就是我一开始就倾向于的，所以我想我可以忍受它。

标签： database filesystems base64

【解决方案1】：

您需要权衡几个因素：

访问速度 如果您将所有文件转储到文件系统中，那么当您有太多文件时，某些文件系统会崩溃或变慢。我见过许多不同的目录分段方案来解决这个问题。
压缩 MySQL 可以轻松压缩您存储的数据。使用文件系统可能更难压缩数据。使用任何类型的压缩压缩也会引起对服务器 CPU 速度的担忧。
备份/恢复 DB 是为轻松备份/恢复而设计的，文件系统的难易程度差异很大。如果您在文件系统中有数据要备份/恢复，那么这会使您的备份/恢复更加复杂，而且复杂在危机中是不好的。
数据丢失容限 使用数据库，您可以操作记录，所有数据都在同一个位置。如果您将数据保存到文件中，则需要使用额外的代码来操作关联的文件，这会引入另一个存在错误和可能的数据丢失的地方。更具体地说，如果您将部分记录存储在文件系统中，而将其余记录存储在数据库中，则需要竭尽全力维护事务完整性。除非您丢失数据，否则没人会关心这一点，因此请注意这方面，即使它看起来并不重要。
复制如果您只需要在一个级别上进行复制，则处理复制问题会更容易。仅将数据存储在数据库中，然后仅复制数据库比为数据库和文件系统执行此操作要容易得多。
繁琐与处理较小的数据库备份相比，处理较大的数据库备份更麻烦。

这些是我想到的首要问题。我尽量不提倡任何一种解决方案，这在很大程度上也取决于您所谈论的文件系统，并且由于未指定，因此您需要自己做出决定。

【讨论】：

感谢您的想法。这些文件将存储在 ext4 文件系统中。从这里的其他 cmets 来看，我可能会选择 FS 存储。

【解决方案2】：

首先，您可以在数据库中存储您喜欢的任何字节（使用适当的“blob”类型）。数据库不需要包含纯字符数据。

其次，将 base64 编码的数据存储在磁盘或数据库中会浪费空间（特别是 25% 的空间）。存储实际字节，然后在离开 HTTP 服务器时对字节进行 base64 编码。

如果您的清除策略如您所指示的那样短，您最好不将数据存储在任何地方，并在每次需要时按需生成。这样一来，您的缓存层就不可能有任何问题，因为没有。

【讨论】：

我不是在问这个，我需要对数据进行 Base64 编码以用于存储以外的目的。
在需要时对数据进行 base64 编码可能会更便宜（在时间、空间和金钱上），而不是实际以这种方式存储。
数据也确实需要存储，即使它是临时的，因为它会在以最终形式提供之前被多次编辑。
听起来您的要求比您在问题中描述的要多得多。
不...我说我正在生成包含 base64 编码数据的 XML 文件。我想知道将这个 XML 文件存储在文件系统上还是存储在数据库中更好。