mysql - 上传的文件 - 数据库与文件系统，使用 Grails 和 MySQL 时

Question

我知道这是一个“经典问题”，但是 mysql/grails(部署在 Tomcat 上)是否对考虑如何处理用户上传文件的存储提出了新的要求。

我喜欢将数据库用于一切(更简单的架构，扩展就是扩展数据库)。但是使用文件系统意味着我们不会用二进制文件来填充 mysql。有些人可能还会争辩说，apache (httpd) 在提供二进制文件方面比 Tomcat 更快，尽管我看到的数字实际上表明，将 Tomcat 放在您网站的前端可能比使用 apache (httpd) 代理更快。

我应该如何选择放置用户上传文件的位置？

感谢您的考虑、时间和想法。

Answer 1

我不知道是否可以对这种决定进行一般性观察，因为这实际上取决于您要尝试做什么以及优先级列表 NFR(例如性能和响应时间)对您的应用程序的影响。

如果您有很多用户，上传大量二进制文件，并且系统为大量上传的二进制文件提供服务，那么在数据库中存储文件的成本包括:

• 大型二进制文件
• 昂贵的查询

好处是

• 原子提交
• 数据库随附扩展(尽管 MySQL 在多节点等方面存在一些问题)
• 管理文件系统等的代码不那么繁琐和复杂

给定存储到文件系统的相同用户情况，您将需要解决

• 缩放
• 文件名管理(用户上传同名文件两次等)
• 在数据库中创建相应的记录以映射到磁盘上的文件(以及围绕所有这些的代码)
• 照管您的 apache 配置，以便它们从文件系统提供服务

对于我们的 Grails 网站，我们有一个类似的问题需要解决，内容编辑每天要上传数百张图片。我们知道，当可以更好地用于其他处理时，通过应用程序驱动所有需求是一种浪费(考虑到页面的预期需求将达到每周数百万，我们绝对不希望图像削弱我们)。

我们最终创建了上传 -> 文件系统解决方案。对于每个上传的文件，都会在上传过程中创建和管理数据库元数据记录(并在生成指向图像的 GSP 内容链接时反过来读取该记录)。我们直接根据浏览器请求的链接通过 Apache 处理磁盘请求。但是，总有一个但是，请记住，对于文件系统之类的东西，每台机器只有内容。

我们很头疼确保图像重新同步到每台服务器上，因为与位于集群后面并使集群行为一致的数据库不同，文件被绑定(bind)到服务器上的物理位置。

文件系统可能遇到的另一个问题是文件夹内容大小。当您开始拥有其中实际上有数万个文件的文件夹时，操作系统级别的文件夹扫描开始真正拖延。为了避免这个问题，我们不得不编写代码来管理图像上传到 yyyy/MM/dd/image.name.jpg 文件夹结构中，这样就没有一个文件夹可以累积数十万张图像。

我的意思是，虽然我们通过不使用数据库来存储 BLOB 而获得了我们想要的性能，但这是以开发开销和系统管理为代价的。