文件存储：CouchDB 与 SQL Server + 文件系统

Question

我正在探索在我们高负载的网站上存储用户上传文件（所有都是 MS Office 文档或类似文件）的不同方法。目前，它被设计为将文档存储为文件，并让 SQL 数据库存储这些文件的所有元数据。当文档数量达到数亿时，我担心存储服务器和 SQL 服务器的性能会超出其能力。我阅读了很多关于 CouchDB 的有用信息，包括其内置的可扩展性和性能，但我不确定在 CouchDB 中将文件作为附件存储与在文件系统上存储文件在性能方面相比如何。

有人使用 CouchDB 集群来存储大量文档并在高负载环境中吗？

Answer 1

回复 Redmumba。CouchDB 开发团队会对您所看到的崩溃感兴趣。

最重要的是：CouchDB 的整个架构都基于早期失败原则。所有子系统以及主服务器都设计为在发生错误时立即终止并恢复。“崩溃”只是正常运行的一部分，它使软件更加可靠（具有讽刺意味的是，但这就是整个 Erlang 哲学）。

至于问题，CouchDB 足以满足要求。CouchDB 的附件流式传输绝对受 IO 限制，非常接近文件系统速度。CouchDB 文档为您提供了元数据所需的所有空间，文档附件将二进制数据保存在附近。无需为此使用不同的系统。

Answer 2

我们在高负载环境中使用 CouchDB 的经历并不好；我们遇到过很多不稳定的情况（频繁崩溃），邮件列表往往指出，只需安装一个监控守护进程，在发生故障时重新启动即可解决。我们不使用大值集，但我们确实经常遇到这种情况——但请记住这一点，因为文件越大，连接时间就越长。这意味着在传输过程中出现故障会更加痛苦，具体取决于带宽和文件大小。

我建议你研究一下MongoDB具有 GridFS 支持。MongoDB 对您来说会很不错（根据您的规范），因为您看起来可能希望将额外的元数据与文件一起存储；由于它是面向文档的，因此您可以将这些元数据与二进制文件一起存储。为此，网格文件系统允许您在数据库中存储大文件。

Answer 3

BBC 似乎正在成功使用它。我相信 TED 上有一个视频讨论了他们如何使用它。

Answer 4

我没有使用过 CouchDB，但我确实有使用 SQL Server 的经验。如果您将文件存储在 SQL Server 中（varbinary(max) 物理存储在文件系统中），我认为您会更好。它将扩展到数十亿行，并且无论使用哪种数据库（oracle、sql server 等），性能都取决于应用程序设计和硬件。我认为这是关键。性能问题几乎总是由于设计不良的应用程序或基础设施造成的，而不是底层企业级数据库。