将媒体存储在数据库中与其他选项
我正在寻求有关存储和检索媒体文件（例如 mp3 文件等）的最佳方法的建议。
这里有人有解决此类问题的经验吗？
我只是在寻找有关如何解决这个特定问题的建议。
谢谢。
I am looking for advice as to the most optimal way to store and retrieve media files such as mp3 files, etc.
Does anyone here have experience with this type of problem?
I'm just looking for suggestions as to how to approach this particular problem.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您没有为您的问题提供任何背景信息，因此我假设是某种基于 CMS Web 的应用程序，因为这是最常见的。
最常用于媒体的方法是将媒体文件存储在磁盘上，并仅将元数据和某种文件 ID 放入数据库中。这使得管理数据库变得更简单（它的大小只是原来的一小部分），并且提供文件更简单、更快（尤其是对于较大的文件）。这种方法的缺点是文件通常不太安全，而且也很难确保文件存储和数据库备份同步。
我们有一个 VLE 系统，可以在本地存储其媒体，并有一个 Oracle 后端来存储其他数据。经过几年的使用，数据库已经增长到 40Gb，加上备份和日志等，但文件存储现在接近 2Tb。作为 DBA，我对这个选择感到非常高兴。尽管我可以随时对数据库进行完整的时间点恢复，但我不确定媒体文件是否也是如此。 2Tb 的 SATA（文件存储）SAN 与 2Tb+ 的光纤通道（数据库）SAN 还可以节省资金（记住+。它可以加起来：对于 Oracle 来说，这意味着更多的重做、临时、RMAN 备份等）。
我们还有一个小型 CMS 来处理主网站上的企业类型页面。这会将（大部分）其媒体放入数据库中。它提供数百个页面并具有 35Gb Oracle 数据库。它足够聪明，可以缓存所有内容，因此不需要一直在数据库中查找内容。这一重要应用程序的所有数据都位于一个相当安全的地方。作为 DBA，我对此也很满意。尽管在这种情况下，CMS 在修订方面确实存在一些怪癖，有时会导致只需进行简单更改即可生成几乎所有数据的新副本。这在数据库中更难管理（重做、撤消、空间恢复等）。
选择地点总是需要权衡。数据库中的空间更昂贵，但如果您的应用程序证明它是合理的，那么它可能是一个不错的选择。什么是“最好的”很大程度上取决于您正在做什么以及您对应用程序及其内容的重要性、安全性、成本和速度的感受。您还需要考虑管理和支持大型数据库的开销 - 许多 DBA 流程都存在扩展问题。您对大型文件系统所做的操作与对小型文件系统没有太大区别。但在数据库中却并非如此。在 40Gb 级别，我们享受 RMAN 中的夜间备份（在线 3 天）、夜间一致数据泵导出（在线 5 天）以及 24 小时闪回。这些都非常好，但在 2Tb 下我们就是无法拥有它们。
我对此给出了 Oracle 的观点，但其中大部分也适用于其他数据库。
You have not given any context to your question so I'll assume a CMS web based application of some kind as this is most common.
The method most often used for media is to store the media files on disk and put only the meta data and a file id of some kind in the database. This makes managing the database simpler (it will be a tiny fraction of the size it would otherwise be) and serving the files is simpler and faster (esp. for larger files). The downside to this approach is that files are often less secure and it is also very difficult to ensure that the file store and database backups are in sync.
We have a VLE system that stores its media locally and has an Oracle backend to store other data. After a few years of use, the database has grown to 40Gb plus backups and log etc but the file store is now close to 2Tb. As the DBA I'm pretty happy about that choice. Although I can do full point-in-time recovery of the database at any point I'm am not sure that is true of the media files. 2Tb of SATA (file store) SAN vs 2Tb+ of Fibre Channel (database) SAN also saves money (remember that +. It can add up: For Oracle this means more redo, temp, RMAN backups etc).
We also have a small CMS that handles the corporate type pages on the main website. This puts (most of) its media into the database. This serves a few hundred pages and has a 35Gb Oracle database. It is clever enough to cache everything so it doesn't need to fish about inside the database for stuff all the time. All the data for this vital application is in one fairly secure place. As the DBA I'm pretty happy with that too. Although in this case the CMS does has a few quirks with revisioning that sometimes have resulted it a new copy of almost all the data for a simple change. This is much harder to manage in the database (redo, undo, space recovery etc).
There is always a trade off in choosing the location. Space in the database is more expensive, but can be a good choice if your application justifies it. What is "best" depends a lot on what you are doing and how you feel about the importance, security, cost and speed of your application and its contents. You also need to consider the overheads of managing and supporting a large database - many DBA process have issues scaling. What you do with large file systems isn't much different to a small one. That just isn't so true in database. At the 40Gb level we enjoy a nightly backup in RMAN, with three days online, a nightly consistent datapump export with 5 days online, and 24 hours of flashback. Those are all very nice but at 2Tb we just could not have them.
I've given an Oracle perspective on this, but much of it applies to other databases too.