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

Question

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

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

所以，我的主要问题是

• 在MySQL中将文件存储为BLOB有什么缺点？
• 像Cassandra这样的NoSQL系统存在同样的问题吗？
• 是否有人有任何其他适当的建议，例如MogileFS等？

Answer 1

不是一个直接的答案，而是一些指向非常有趣和某种类似问题的指针（是的，它们是关于blob和图像，但这与IMO相当）。

  

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

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

  

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

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

PS：我不想成为killjoy，但我不认为任何NoSQL解决方案都能解决你的问题（NoSQL对大多数企业来说都无关紧要）。

Answer 2

可能是混合解决方案。

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

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

Answer 3

您可以在Cassandra中轻松存储最大2GB的文件，方法是将它们分成1MB左右的列。这很常见。

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

Answer 4

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

另一个缺点是，处理db中的文件比处理文件系统级别的文件有更多的开销。但是，只要优势超过了缺点，并且看起来可能在你的情况下，你可以尝试一下。

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