对于集群的 CouchDB 设置，我应该继续使用 BigCouch 吗？答案

【问题标题】：For a clustered CouchDB setup, should I just go ahead and use BigCouch?对于集群的 CouchDB 设置，我应该继续使用 BigCouch 吗？
【发布时间】：2013-01-05 13:11:54
【问题描述】：

我一直在研究CouchDB 的附件功能。基本上，CouchDB 允许您将二进制文件数据存储在数据库记录中。类似于 MongoDB 的 GridFS。我想要构建的项目主要围绕文件上传展开，我计划将其存储在 CouchDB 中。因此，这导致我研究 CouchDB 如何对数据进行集群，以便随着我的数据库增长，由于文件附件的存在，我可以将它集群到多个服务器上。我很失望地发现 CouchDB 没有能力做到这一点，开箱即用。 CouchDB 指南说要使用名为 couchdb-lounge 的东西，但该项目在 Github 上已经超过 2 年未动过。我不认为我会觉得以此为基础。

我找到了BigCouch，它似乎是经过修改的 CouchDB，具有我需要的确切集群功能，只是它看起来落后于当前稳定的 CouchDB 版本。我确实在一年前的新闻稿中读到，他们正在努力将 BigCouch 合并到官方 CouchDB 中，但我不知道具体的时间表是什么样的。

作为第三种选择，看起来 Couchbase Server 2 也基于 CouchDB，但具有构建的集群以及其他功能。我也在辩论这是一个可行的选择。但它不支持文件附件。

BigCouch 最终将登陆 CouchDB 的事实让我有信心继续使用 BigCouch。

我应该使用 BigCouch 吗？如果只是 CouchDB + 集群，为什么不是每个人都使用 BigCouch？肯定有什么不好的吧？

【问题讨论】：

标签： couchdb cluster-computing bigcouch

【解决方案1】：

在我的工作中，我的需求与您的需求有些不同，但我已经完成了 Couchbase、CouchDB 和 BigCouch 的工作。我发现 BigCouch 很容易在云中设置，并且只用了一天就成功创建了一个集群。我们正在投资 BigCouch，并在尽职调查后致力于一项重大的移动计划。

原因：

BigCouch 在云环境中的设置相当容易。文档很简单，但我能够快速启动并运行一个简单的集群。我建议密切关注云环境中机器的私有主机名。（如果有帮助，我可以发送我在云端创建机器的详细说明。）
BigCouch 由 Cloudant 维护，当然它是开源的，这很好。 Cloudant 的 CTO 告诉我，他们已经将相当多的代码合并到 Apache CouchDB 项目中。此外，Cloudant 看起来相当稳定，因此我们指望他们让项目保持最新。这似乎是一个不错的社区（与 TouchDB 不同）。
据我所知，BigCouch 主要围绕核心 CouchDB 代码/API 进行包装。这很好，因为这让我觉得他们以 CouchDB 为基础，并没有尝试在此基础上做太多事情。例如，CouchDB 的复制已经非常好，BigCouch 并没有尝试重新发明轮子。他们只是添加了一些 Couch 缺少的东西。
与 Cloudant 相比，“原始”运行 BigCouch 的一个缺点是 Cloudant 维护自己的具有更多功能的内部分支。我们的评估发现，虽然这些功能是不需要的。他们对我们来说有点矫枉过正。
Couchbase 似乎落后了一步。到达 Couchbase 2.0 花了很长时间，我对 2.0 之前的 Couchbase 感到失望。我听说 2.0 很棒，但还没有机会使用它。由于各种原因，我对 2.0 之前的版本感到有点厌烦。

【讨论】：

【解决方案2】：

不是每个人都需要集群。 CouchDB 团队打算在几乎准备好的 1.3 版本发布后不久合并 BigCouch，因此开始研究 BigCouch 肯定是有道理的（我个人肯定会选择 BigCouch 而不是 CouchBase 或 couchdb-lounge —— 许多 BigCouch 的贡献者都是 CouchDB无论如何，提交者）。

【讨论】：

【解决方案3】：

集群的缺点是它的额外复杂性。我会争辩说，除非您已经是一位经验丰富的 CouchDB 用户，否则从第一天开始使用 BigCouch 可能有点过头了。

作为学习如何设置和维护 BigCouch 部署的替代方法，您可以使用 Cloudant 等在线 CouchDB 主机，让他们处理管理机器集群的复杂性。您所处理的只是看起来仍然像您本地 CouchDB 实例的东西。

关于在 CouchDB 中存储文件，为什么不将它们存储在 S3 中？（顺便说一句，比 Cloudant 便宜很多）

【讨论】：

我目前确实将它们存储在 S3 中，但是与将它们与所有其他数据存储在同一个数据库中相比，这增加了很多额外的复杂性。使用 S3，我必须创建数据库记录、上传到 S3、使用 URL 更新记录、在需要公开访问时为 URL 签名等等。只是很多额外的工作。我只是在寻找替代品。
为了它的价值：我们做了类似的事情 CouchDB + S3 除了我们不公开 S3，我们代理它以允许我们稍后更改存储。最初我们使用 CouchDB 附件，但在 Cloudant 与 S3 中它们会太贵。在我们的案例中没有太大的复杂性差异。（多个附件文档链接到 1 个主文档）。我会对这两种方法的替代方案感兴趣。
我目前向最终用户公开 S3 以进行上传和下载的原因是，带宽可以通过 S3 设置的任何负载平衡和东西来引导。如果我首先通过 EC2 实例代理它，那可能只会在那里造成瓶颈。尽管如此，能够在最终用户不知情的情况下无缝更改文件的提供位置是有好处的。