视频文件的保存位置 - 数据库还是磁盘

发布于 2024-09-14 19:32:48 字数 142 浏览 7 评论 0原文

将视频文件作为 BLOB 对象存储在数据库中还是存储在物理磁盘上是一个好主意。

这是一个类似于 youtube 的网站,用户可以在其中上传视频并观看它们

数据库将是 Mysql

哪个选项更好以及为什么

谢谢

Is it a good idea to store video files in a database as BLOB objects or store them on a physical disk.

This is for a site similar to youtube where users can upload their video and view them

Database would be Mysql

Which option is better and why

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

灯角 2024-09-21 19:32:48

专业 MySQL:
- BLOB 可能受外键约束,从而使数据库保持冗余,而不是保存到文件系统。在这种情况下,您必须编写删除文件的程序。
- 细粒度的用户权限。

缺点:
- MySQL 不是免费运行的,它会产生开销,而不是从文件系统提供服务。
- Web 服务器无法直接从数据库提供 BLOB。这意味着 PHP 必须调解该过程。当 BLOB 从 MySQL 加载到 PHP 中时,内存使用量至少与 BLOB 一样大。因此,在文件可能达到数百 MB 的情况下,这会给网络服务器带来巨大的压力。

实际上,MySQL 并不是用来保存文件的。 BLOB 主要用于保存大量序列化数据,例如缓存。

Pro MySQL:
- The BLOB may be subject to foreign keys and thus keeping the database redundant as opposed to saving to the filesystem. In this case you have to program the deleting of the file.
- Finegrained user permissions.

Con:
- MySQL doesn't run for free, it comes with overhead as opposed to the serving from the filesystem.
- Webservers can't directly serve BLOBs from the database. This means PHP will have to mediate the process. When the BLOB gets loaded from MySQL into PHP, the memory usage will be atleast as large as the BLOB. So in your case where files could be running into the hundreds of MB's this would put enormous strain on the webserver.

In all reality MySQL isn't ment to be used to save files. BLOBs are mostly used to save lare ammounts of serialized data such as caches.

清风无影 2024-09-21 19:32:48

我使用 NFS 存储媒体内容大约 5 年,从存储角度来看没有出现任何问题。
操作、编码和保存通过 ffmpeg、php 脚本和 cron 作业进行管理。
视频元数据存储在 MySql 数据库中,并通过 Nginx 提供 Web 传输(通过只读 NFS 安装)。
在此环境中视频文件大小高达 2GB。
也许我可以在另一个数据库引擎上运行得更快,但是,真正的时间浪费是由于编码过程而不是保存文件。

当我保存数千个小图像(如头像)时,我只使用 MySql 来存储文件元数据(图像路径和其他属性),而不是将文件保存在 BLOB 字段中,BLOB 字段可能会在繁重的查询中减慢数据库速度。

I'm using NFS to store media content from about 5 years with no issues on storage perspective.
Manipulating, encoding and saving are managed via ffmpeg, php scripts and cron jobs.
Video metadata are stored in a MySql database and web delivery is provided via Nginx (via a read only NFS mount).
Video files size up to 2GB in this environment.
Probably I can go faster on another db engine but, the real time waste is due to the encoding process and not for saving files.

When I'm saving thousands of little images (like avatars) I ever use MySql just to store files metadata (image path and other properties) and not to save file in a BLOB field who can slow down the db too much on heavy queries.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文