5

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

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

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

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

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

4

3 回答 3

2

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

原因：

  1. BigCouch 在云环境中设置起来相当容易。文档很简单，但我能够快速启动并运行一个简单的集群。我建议密切关注云环境中机器的私有主机名。（如果有帮助，我可以发送我在云中创建机器的详细说明。）

  2. BigCouch 由 Cloudant 维护，当然它是开源的，这很好。Cloudant 的 CTO 告诉我，他们已经将相当多的代码合并到 Apache CouchDB 项目中。此外，Cloudant 看起来相当稳定，因此我们指望他们让项目保持最新。这似乎是一个很好的社区（不像 TouchDB 之类的东西）。

  3. 据我所知，BigCouch 主要围绕核心 CouchDB 代码/API 进行包装。这很好，因为这让我觉得他们以 CouchDB 为基础开始，并没有尝试在此基础上做太多事情。例如，CouchDB 的复制已经非常好，BigCouch 并没有尝试重新发明轮子。他们只是添加了一些 Couch 缺少的东西。

  4. 与 Cloudant 相比，“原始”运行 BigCouch 的一个缺点是 Cloudant 维护自己的具有更多功能的内部分支。我们的评估发现，虽然这些功能是不需要的。他们对我们来说有点矫枉过正。

  5. Couchbase 特别似乎落后了一步。到达 Couchbase 2.0 花了很长时间，我对 2.0 之前的 Couchbase 感到失望。我听说 2.0 很棒，但还没有机会使用它。由于各种原因，我对 2.0 之前的版本感到有点厌烦。

于 2013-01-05T05:11:54.207 回答
1

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

于 2012-12-18T11:48:08.910 回答
0

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

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

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

于 2012-12-18T14:51:36.780 回答