5

我正在编写一个完全围绕文件上传的简单 Web API。用户可以通过基于 HTTP 的 API 将文件上传到服务，服务将生成文件供用户访问，并且还需要将它们与上传的文件一起存储。所以会有很多文件在玩。

基本上，我试图在将这些存储在 CouchDB 中和将它们存储在类似 Amazon 的 S3 中之间做出决定。

使用 CouchDB，我可能会为用户上传的初始文件提供一个文档，其中附件数据内联在 _attachments 集合中。系统制作的其他文件将添加到该文档中。（服务做文档转换，所以他们上传Excel XLS，系统生成PDF、TXT等。）我觉得这样很好，因为上传的文档记录一次删除也会删除生成的PDF、TXT或任何其他附件。

使用 S3，我知道我正在使用完全专用于单个文件存储的托管解决方案，我感到很安全。它还将带宽专门用于这些文件，并且不会来自我的 API Web 服务器。缺点是它为我的 API 代码添加了很多额外的逻辑，现在我必须让很多远程文件与我的本地 CouchDB 数据库所知道的内容保持同步。此外，如果我希望最终用户直接从 S3 访问文件，我将不得不处理请求签名等问题。文档都是单独存储的，因此从 CouchDB 中删除用户上传的附件将需要我对 S3 进行多次删除查询以获取其他文件。

我熟悉 S3，并在当前项目中使用它，但 CouchDB 在允许附件方面看起来非常棒。我很想使用它，但有什么问题或缺点吗？在我上面描述的场景中，CouchDB 附件是否比 S3 更有意义，存储了大量上传的文件？

4

3 回答 3

1

根据我的经验，当涉及大量二进制对象时，数据库引擎会变得有些不稳定，除非它们是专门为此而构建的。

我一直在 CouchDB 中保存（低分辨率）图像，但我遇到了几千兆字节的附件。因此，我将附件移至 S3 并且从未回头。

于 2020-11-20T13:24:38.110 回答
0

两种解决方案都非常明智：各有利弊。

您没有提到将文件存储为 CouchDB 附件的一个优点是它们将与数据一起复制。它使连续备份变得更容易，并且在您的快照中，您的数据将与您的文件保持一致。

于 2013-01-27T11:34:53.863 回答
0

我已经成功地将 couchdb 用于许多项目和几个类似的项目。您在使用 couchdb 的盒子里得到了这么多。我的问题是你的文件的平均大小是多少，你认为你的数据库会有多大？

于 2012-12-27T18:08:58.823 回答