在mysql数据库中存储大文件/二进制数据:什么时候可以吗？

Question

好的,我已经搜索了这个,并阅读了关于在[MySQL]数据库中存储二进制数据的几点观点.一般来说,我认为这是一个坏主意,并试图避免它,支持传统的文件传输,只是在数据库中存储对文件的引用.

但是,我正在开发一个项目,该项目需要与远程/云数据库进行数据库同步,不仅适用于文件,还适用于设置和其他用户内容.出于这个原因和其他原因,我觉得这可能是数据库中二进制存储的合适情况.

我已经为数据库同步编写了一个通用系统,它可以很好地使用Reflection和XML.我也(以我的直觉)将文件存储集成到这个系统中.再次,它运行良好 - 我将文件切换到64Kb BLOB并将它们存储在一个表中,带有file_id引用(链接到一个单独的表,其中包含元数据,如文件名/大小/ mime类型).

这使我能够在连接可用时发送碎片,并允许我限制每个请求大小以保持平稳运行.

到目前为止,我还没有发现任何问题,并已成功导入和传输超过1GB的数据(超过10-15个文件/ 16000行),但我担心它的可扩展性 - 一旦有了它会减慢20gb +数据在那里,或者MySQL可以处理它,只要我的查询结构良好？

我决定将数据存储在数据库中的另一个原因是,我认为如果空间不足,我可以简单地向MySQL添加另一个HDD /存储设备,以期有效扩展/复制/等.

我非常感谢任何观点或评论是关于这是一个好的还是坏的方法,并且我错过了我曾经在生产环境中使用过的任何明显的问题？

编辑:我忘了提一下,文件大小可以从1KB到1GB不等

[粗略]结论 首先:非常感谢那些提出了经过深思熟虑的答案的人.在这里选择接受的答案非常困难,因为每个人都有一些体面的东西可供选择.

最后(尽管我的希望),我已经决定纯粹的MySQL存储服务器充其量只是一个好的解决方案(我仍然不禁想知道为什么他们打扰包括BLOB类型).

作为替代方案,我在@Nick Coons文件系统方法和@ tadman使用轻量级键/值数据库引擎(如leveldb)的混合建议之间徘徊.如果在这个项目中使用leveldb的实用性不是问题,这很可能是我将努力的方法.

我已经在此基础上接受了tadman的回答; 他的回答对我的情况也是最适用和有用的.

话虽如此,对于那些感兴趣的人:到目前为止,我只使用MySQL获得了很多成功.我已经测试了一个存储超过15gb二进制数据的表,没有任何明显的负面影响,从大表中插入/检索数据(仔细查询).但是,我确信这仍然是非常低效的,所提到的任何替代方法都会明显更好.

Answer 1

我想知道为什么你还要为数据库烦恼，当你在顶部添加的用于分块、存储、检索和重组的层在定义良好的文件系统结构上也能正常工作时。MySQL 希望将其所有数据存储在一个卷上，因此不需要随时添加另一个驱动器，并且大量二进制数据的复制将极其缓慢，因为二进制日志最终会复制大量数据您需要存储的数据。

最简单的方法往往是最好的方法。直接将其存储在文件系统中可能是最好的方法。如果您需要保留存储内容的索引，也许您会使用 MySQL 等数据库，但有很多方法可以完成相同的任务。科技含量越低越好。例如，不要排除SQLite，因为嵌入式数据库在轻读写负载下性能非常好，并且在备份和恢复时具有“只是一个文件”的优势。

话虽如此，您正在做的事情听起来与LevelDB非常相似，因此在您采用您的方法之前，您必须了解它与此类键值文档存储有何显着不同。