Web 应用程序的文件存储：文件系统、数据库和 NoSQL 引擎

Posted 2023-02-23

【中文标题】Web 应用程序的文件存储：文件系统、数据库和 NoSQL 引擎

【英文标题】：File Storage for Web Applications: Filesystem vs DB vs NoSQL engines

【发布时间】：2011-02-22 20:15:13

【问题描述】：

我有一个存储大量用户生成文件的 Web 应用程序。目前这些都存储在服务器文件系统上，这对我来说有几个缺点。

当我们移动“文件夹”（由我们的应用程序定义）时，我们还必须移动磁盘上的文件（尽管这更多是由于原始开发人员的奇怪设计决定，而不是需要将内容存储在文件系统）。 很难为文件系统操作编写测试；我有一个模拟文件系统类，它记录诸如移动、删除等操作，而不执行它们，这或多或少可以完成这项工作，但我对测试没有 100% 的信心。 我将添加一些其他工作，这些工作需要从其他服务访问文件以执行其他任务（例如在 Solr 中编制索引、生成缩略图、电影格式转换），因此我需要远程获取这些文件。通过网络共享执行此操作似乎很狡猾... 过去处理文件系统的权限有时会给我们带来问题，尽管现在我们已经转移到纯 Linux 环境，这应该不成问题了。

所以，我的主要问题是

在 mysql 中将文件存储为 BLOB 有哪些缺点？ NoSQL 系统（如 Cassandra）是否存在同样的问题？ 是否有人有任何其他可能合适的建议，例如MogileFS 等？

【参考方案1】：

不是一个直接的答案，而是一些指向非常有趣且在某种程度上相似的问题的指针（是的，它们是关于 blob 和图像，但这是 IMO 可比的）。

在 MySQL 中将文件存储为 BLOB 的缺点是什么？

Storing Images in DB - Yea or Nay? Images in database vs file system https://***.com/search?q=images+database+filesystem

像 Cassandra 这样的 NoSQL 系统是否存在同样的问题？

NoSQL for filesystem storage organization and replication? Storing images in NoSQL stores

PS：我不想成为杀手，但我认为任何 NoSQL 解决方案都无法解决您的问题（NoSQL 与大多数企业无关）。

【讨论】：

谢谢，看起来是一组非常有用的链接。存储任何类型的图像/blob 是我所追求的（我们正在存储各种东西）。

谢谢，您建议的链接很棒。显然，在提问之前我需要更加努力地搜索:) 总之，避免使用 DB 似乎是要走的路。我只需要将应用程序与文件系统解耦，这样就不会那么痛苦了……

很高兴您发现它们很有用。我同意这个结论。

【参考方案2】：

也许是一种混合解决方案。

使用数据库存储有关每个文件的元数据 - 并使用文件系统实际存储文件。

“文件夹”的任何重组都可以在数据库中建模并从实际操作系统位置取消引用。

【讨论】：

这就是我们目前所做的；理想情况下，文件夹的重组应该完全从实际的文件系统位置取消引用，但是老开发人员不遗余力地链接它......所以无论如何我都面临着某种程度的重写，我想知道如果有合适的方法可以完全避免文件系统。

如何取消对操作系统位置的引用？

这里的取消引用意味着文件系统位置可能固定在某个目录中，但数据库有另一种标记位置的方式，可能看起来像文件夹层次结构，但与物理位置不同- 然后这些链接就像一些正常的 FK 关系

【参考方案3】：

您可以通过将文件拆分为 1MB 左右的列，在 Cassandra 中轻松存储高达 2GB 的文件。这很常见。

您也可以将它存储为一个大列，但是在访问它时您必须将整个内容读入内存。

【参考方案4】：

如果操作系统或应用程序不需要访问文件，那么就没有真正需要将文件存储在文件系统上。如果您想在备份数据库的同时备份文件，那么将它们存储在数据库之外的好处就更少了。因此，将文件存储在数据库中可能是一种有效的解决方案。

另一个缺点是在 db 中处理文件比在文件系统级别处理文件的开销更大。但是，只要利大于弊，而且在您的情况下似乎可以，您可以尝试一下。

我主要关心的是管理磁盘存储。随着您的数据库文件变大，管理整个数据库变得更加复杂。你不想从煎锅里搬出来扔进火里。

【讨论】：

我不太关心磁盘空间；这些天它非常便宜，我可以添加更多驱动器并在必要时对其进行 RAID。我对 mysql 的关心主要与缓存有关；如果我运行一个返回 BLOBS 的查询，这似乎会占用大量缓存，从而清除其他更有用的数据。我怀疑肯定还有其他问题，否则会有更多人这样做，但我不确定它们是什么。

我已经阅读了很多关于这个主题的内容，没有人将查询缓存问题作为不在数据库中存储文件的理由。使用 MySQL，您可以设置 query_cache_limit 值，该值指示要缓存的最大结果集大小。默认值为 1 MB。作为可能解决文件系统问题的替代解决方案，您还可以查看 NFS（文件服务器）。您可以在数据库中存储对文件的引用。

没错，限制要存储在查询缓存中的东西的大小可能会减少我在这里的担忧。存储文件系统引用仍然很痛苦，但看起来这是最好的方法。