在数据库中存储媒体文件的最佳方式是什么？答案

【问题标题】：What is the best way to store media files on a database?在数据库中存储媒体文件的最佳方式是什么？
【发布时间】：2010-09-14 08:36:54
【问题描述】：

我想在数据库中存储大量的声音文件，但我不知道这是否是一个好习惯。我想知道这样做的利弊。

我还考虑过为这些文件提供“链接”的可能性，但也许这会带来比解决方案更多的问题。欢迎任何这方面的经验:)

注意：数据库将是 MySQL。

【问题讨论】：

标签： mysql database audio multimedia

【解决方案1】：

存储音频/视频文件的最佳方式，您可以使用本地或云端的任何分布式存储。

https://min.io/

对于云： AWS S3

【讨论】：

【解决方案2】：

将它们存储为外部文件。然后将路径保存在 varchar 字段中。将大型二进制 blob 放入关系数据库通常效率非常低 - 它们只会占用空间并且在缓存被填充时减慢速度是不可用的。而且没有任何收获 - 无法搜索 blob 本身。不过，您可能希望将媒体元数据保存到数据库中。

【讨论】：

【解决方案3】：

使用 blob 存储文件的一些优点

降低管理开销 - 使用单一工具进行备份/恢复等
数据库和文件系统不可能不同步
事务能力（如果需要）

一些缺点

用可用于存储行、索引等的无用垃圾来炸毁数据库服务器的 RAM
使您的数据库备份非常大，因此不易管理
不像文件系统那样方便地为客户端提供服务（例如使用 Web 服务器）

性能怎么样？你的旅费可能会改变。文件系统千差万别，数据库的性能也千差万别。在某些情况下，文件系统会胜出（可能有更少的大文件）。在某些情况下，数据库可能会更好（可能包含大量小文件）。

无论如何，别担心，做当时看起来最好的事情。

一些数据库提供内置的网络服务器来提供 blob。在撰写本文时，MySQL 还没有。

【讨论】：

将文件存储为 blob 会导致 OutofMemoryError 吗？我正在处理我的应用程序中的许多文件并将文件作为编码字符串存储在 android sqllite 数据库中，当总文件大小达到 20 mb 时会导致 OutofMemoryError，其中可能包括数百个文件。使用 blob 会导致同样的问题吗？ ?

【解决方案4】：

我已经在不同的项目中尝试了两种方式，我们最终决定使用文件系统也更容易。毕竟，文件系统已经针对存储、检索和索引文件进行了优化。

我对此的一个提示是仅在数据库中存储文件的“根相对”路径，然后让您的程序或查询/存储过程/中间件使用安装特定的根参数检索文件。

例如，如果您将 XYZ.Wav 存储在 C:\MyProgram\Data\Sounds\X\ 中，则完整路径为

C:\MyProgram\Data\Sounds\X\XYZ.Wav

但是您可以将数据库中的路径和/或文件名存储为：

X\XYZ.Wav

在其他地方，在数据库或程序的配置文件中，存储根路径，如 SoundFilePath 等于

C:\MyProgram\Data\Sounds\

当然，从数据库路径中拆分根目录的位置取决于您。这样，如果您移动程序安装，您就不必更新数据库。

另外，如果会有很多个文件，请找到一些散列路径的方法，这样您就不会在一个目录中包含数百或数千个文件（在我的小示例中），有基于文件名的第一个字符的子目录，但您可以更深入或使用随机哈希）。这也让搜索索引器很高兴。

【讨论】：

【解决方案5】：

我所知道的每个存储大量大文件的系统都将它们存储在数据库外部。您将文件的所有可查询数据（标题、艺术家、长度等）以及文件的部分路径存储在数据库中。当需要检索文件时，您提取文件的路径，在其前面添加一些文件根（或 URL），然后返回。

因此，您将有一个“位置”列，其中包含部分路径，例如“a/b/c/1000”，然后您将其映射到： "http://myserver/files/a/b/c/1000.mp3"

确保您有一种简单的方法可以将媒体数据库指向不同的服务器/目录，以防您需要进行数据恢复。此外，您可能需要一个将数据库与文件存档内容重新同步的例程。

此外，如果您要拥有数千个媒体文件，请不要将它们全部存储在一个巨大的目录中 - 这对某些文件系统来说是一个性能瓶颈。相反，将它们分解为多个平衡的子树。

【讨论】：

好帖子！我不是在抄袭你，我是在你发帖时输入我的答案:-)
此实现存在可扩展性问题，当您获得 2 个以上的网络服务器时。
在我们的案例中，可扩展性解决方案是一个专用服务器，用于存储文件，并在其上运行 Web 服务以进行归档和检索。你给它一个文件，它存储它并告诉你它放在哪里。任意数量的前端应用服务器都可以从中存储和检索文件。
我并没有真正得到“可扩展性”的评论。如果您将媒体存储在数据库中，您仍然可以在一个地方获取文件，但这将是一个开销更高的操作。
可扩展性伴随着更大规模的设计。您查询主集群。他们知道所有文件的存储位置以及可用的存储服务器。然后根据来自它们的数据，连接到任意数量的存储服务器进行存储/检索。

【解决方案6】：

我认为将它们存储在数据库中是可以的，只要您使用良好的实现即可。您可以阅读这篇较早但很好的文章，了解如何防止数据库中的大量数据影响性能。

http://www.dreamwerx.net/phpforum/?id=1

我已经在 mysql 数据库中加载了 100 个演出，没有任何问题。设计和实现是关键，做错了，你会受苦。

更多数据库优势（尚未提及）： - 在负载平衡的环境中工作得更好 - 您可以构建更多的后端存储可扩展性

【讨论】：

我正在考虑使用这个.. 我希望这个东西仍然很好，或者还有更好的解决方案吗？

【解决方案7】：

使用数据库的优点：

轻松将声音文件与其他文件合并数据位。
避免文件 i/o 操作绕过数据库安全。
无需分离操作数据库时删除声音文件记录被删除。

使用数据库的缺点：

数据库膨胀
数据库可能比文件系统更昂贵

【讨论】：

【解决方案8】：

您可以将它们存储为 BLOB（或 LONGBLOB），然后在您想要实际访问媒体文件时检索数据。

或

您可以简单地将媒体文件存储在驱动器上，并将元数据存储在数据库中。

我倾向于后一种方法。我不知道这在世界上是如何做到的，但我怀疑很多其他人也会这样做。

您可以存储链接（数据的部分路径），然后检索此信息。可以轻松地在驱动器上移动东西并仍然可以访问它。

我将每个文件的相对路径与有关文件的其他元数据一起存储在数据库中。如果我需要将实际数据重新定位到另一个驱动器（本地或通过 UNC 路径），则可以即时更改基本路径。

我就是这样做的。我相信其他人也会有想法。

【讨论】：

【解决方案9】：

一个简单的解决方案是将文件的相对位置存储为字符串并让文件系统处理它。我已经在一个项目上尝试过（我们将办公文件附件存储到调查中），效果很好。

【讨论】：

你是如何处理文件命名的？