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

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

我也想过有可能与这些文件有“联系”，但是这可能会带来比解决scheme更多的问题。 任何在这方面的经验都会受到欢迎:)

注意：数据库将是MySQL。

我所知道的每一个存储大量大文件的系统都将它们存储在数据库的外部。 将文件（标题，艺术家，长度等）的所有可查询数据连同文件的部分path一起存储在数据库中。 当检索文件的时候，你需要提取文件的path，在文件的根目录（或者URL）前加上一个文件，然后返回。

所以，你会有一个“位置”列，里面有一个部分path，比如“a / b / c / 1000”，然后映射到：“ http：// myserver / files / a / b / c /1000.mp3 “

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

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

我认为把它们存储在数据库中是可以的，只要你使用一个好的实现。 您可以阅读这篇较早的文章，了解如何让数据库中的大量数据不会影响性能。

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

我已经从字面上加载了100个数据库，没有任何问题。 devise和实施是关键，做错了，你会受苦。

更多数据库优势（尚未提及）： – 在负载均衡的环境中更好地工作 – 您可以构build更多的后端存储可伸缩性

使用数据库的优点：

  • 易于join其他数据位的声音文件。
  • 避免绕过数据库安全性的文件I / O操作。
  • 当数据库logging被删除时，不需要分离操作来删除声音文件。

使用数据库的缺点：

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

我已经在不同的项目中尝试过两种方法，而且我们终于决定使用文件系统也更容易。 毕竟，文件系统已经被优化用于存储，检索和索引文件。

我将要提到的一个技巧是只存储数据库中文件的“根相对”path，然后让程序或查询/存储过程/中间件使用安装特定的根参数来检索文件。

例如，如果将XYZ.Wav存储在C：\ MyProgram \ Data \ Sounds \ X \中，则完整path将是 

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

但是，您可以将path和或文件名存储在数据库中，如下所示： 

 X\XYZ.Wav

在其他地方，在数据库或程序的configuration文件中，存储一个类似于SoundFilePath的根path

C：\ MyProgram \ DATA \声音\

当然，从数据库path拆分根的地方取决于你。 这样，如果你移动你的程序安装，你不必更新数据库。

另外，如果要有大量的文件，可以找一些散列path的方法，这样就不会出现一个包含数百或数千个文件的目录（在我的例子中，有一些子目录是基于文件名，但你可以更深入或使用随机哈希）。 这使得search索引者也很高兴。

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

要么

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

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

您可以存储链接（数据的部分path），然后检索这个信息。 使移动硬盘上的东西变得很容易，并且仍然可以访问它。

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

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

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

  • 降低pipe理开销 – 使用一个工具来备份/恢复等
  • 数据库和文件系统不可能不同步
  • 交易能力（如果需要）

一些缺点

  • 用无用的垃圾炸毁你的数据库服务器的RAM，它可以用来存储行，索引等
  • 使您的数据库备份非常大，因此pipe理更less
  • 不如文件系统为客户提供服务（例如使用Web服务器）

性能呢？ 你的旅费可能会改变。 文件系统是非常不同的，数据库也是如此。 在某些情况下，文件系统将会赢得（可能只有更less的大文件）。 在某些情况下，数据库可能会更好（也许有很多小文件）。

无论如何，不​​要担心，做当时最好的事情。

一些数据库提供了一个内置的web服务器来提供blob。 在撰写本文时，MySQL并没有。

将它们存储为外部文件。 然后将path保存在varchar字段中。 将大的二进制blob放入关系数据库通常效率非常低 – 它们只占用空间，并且在caching被填充时放慢速度是不可用的。 没有什么可以获得的 – 这些斑点本身是不能被search的。 尽pipe您可能希望将媒体元数据保存到数据库中。

一个简单的解决scheme就是将文件的相对位置存储为string，并让文件系统处理它。 我已经尝试了一个项目（我们正在存储办公室文件附件调查），它工作正常。

Interesting Posts