Database design 在数据库中存储媒体与其他选项

我正在寻找关于存储和检索媒体文件（如mp3文件等）的最佳方法的建议

这里有人有过这种问题的经验吗

我只是想听听关于如何解决这个特殊问题的建议

---

谢谢。

您还没有给出您的问题的任何上下文，因此我将假设使用某种基于CMS的web应用程序，因为这是最常见的

媒体最常用的方法是将媒体文件存储在磁盘上，并仅将元数据和某种类型的文件id放入数据库中。这使得管理数据库变得更简单（它的大小将是原来的一小部分），并且为文件提供服务更简单、更快（尤其是对于较大的文件）。这种方法的缺点是文件通常不太安全，而且很难确保文件存储和数据库备份同步

我们有一个本地存储媒体的VLE系统，并有一个Oracle后端来存储其他数据。经过几年的使用，数据库已经增长到40Gb，加上备份和日志等，但文件存储现在接近2Tb。作为DBA，我对这个选择感到非常高兴。虽然我可以在任何时候对数据库进行完整的时间点恢复，但我不确定媒体文件是否如此。2Tb的SATA（文件存储）SAN与2Tb+的光纤通道（数据库）SAN相比也节省了资金（请记住+。这可以加起来：对于Oracle来说，这意味着更多的重做、临时、RMAN备份等）

我们还有一个小型CMS，用于处理主网站上的公司类型页面。这会将（大部分）媒体放入数据库。它提供几百页的服务，并有一个35Gb的Oracle数据库。它足够聪明，可以缓存所有内容，因此它不需要一直在数据库中搜寻东西。这个重要应用程序的所有数据都在一个相当安全的地方。作为DBA，我对此也很满意。尽管在这种情况下，CMS在修改方面确实有一些怪癖，有时会导致它为一个简单的更改生成几乎所有数据的新副本。这在数据库中很难管理（重做、撤消、空间恢复等）

在选择地点时总是要权衡。数据库中的空间比较昂贵，但如果应用程序证明这一点，那么它可能是一个不错的选择。什么是“最佳”在很大程度上取决于您正在做什么，以及您对应用程序及其内容的重要性、安全性、成本和速度的看法。您还需要考虑管理和支持大型数据库的开销——许多DBA进程都存在缩放问题。使用大型文件系统与使用小型文件系统没有太大区别。在数据库中就不是这样了。在40Gb级别上，我们享受RMAN的夜间备份，三天在线，夜间一致的数据泵导出，五天在线，24小时闪回。这些都很好，但是2Tb的话我们就不能拥有它们了

我从Oracle的角度对此进行了阐述，但其中大部分内容也适用于其他数据库