我想将一个现有应用程序（该应用程序在关系数据库中存储了大约 1000 万条记录）迁移到 CouchDB。我喜欢 CouchDB 的地方在于它易于复制且缓存视图速度快。我不喜欢的地方在于它的写入和视图创建速度，如果存储 1000 万条文档，速度会非常慢。
为了解决这些潜在的瓶颈，我必须采取三个 CouchDB 实例：
- 只写实例：这是主实例。我们唯一的事实点。这里只允许更新、插入和删除。此实例上没有读取和查看。
- 仅查看创建实例：仅用于创建和缓存视图。此实例上没有读取或写入操作。
- 只读实例：通过复制视图进行读取访问。
实例 2 是从实例 1 复制的。由于不会有任何应用程序使用实例 2，因此可以在不影响生产应用程序的情况下创建新视图。
实例 3 从实例 2 复制而来，其中包含所有缓存视图。
这是一个可行的解决方案吗？
答案1
我相当确定 CouchDB 不会复制视图缓存（毕竟它们是缓存），所以你必须复制那些带外缓存（在我看来，这有点偏离了重点）。
CouchDB 可能不太适合写入密集型负载。如果您的负载毕竟是读取密集型负载，我猜您可以在每次插入/更新后调用视图，这样视图就始终完全缓存支持。
免责声明：我在一些网站上使用了 CouchDB，但远没有达到您所说的规模。
答案2
我从来没有运行过 CouchDB，只是研究过它，所以不要在未经验证的情况下将我的建议视为正确的……
首先，我强烈建议阅读 John P. Wood 的系列文章，了解他在生产中使用 CouchDB 的经验：http://johnpwood.net/2009/06/15/couchdb-a-case-study/
接下来，当您说实例时，是指具有单个 CouchDB 实例的物理服务器吗？如果我们只谈论 3 台服务器，我认为通过分配不同的角色来划分容量并不是最佳选择。我的直觉是让所有 3 台服务器保持相同并加载完整的数据集，以允许并行读取查询......？
如果只有 3 台服务器，我会考虑使用传统的 RDBMS 和传统的复制设置。我怀疑 CouchDB 能否在计算能力相对较弱的情况下为您带来如此大的变化？
另外，请仔细研究一下 HBase，它是在 Hadoop 之上构建的。Hadoop 框架现在得到了众多企业的大力支持，雅虎和 Facebook 都是其大用户。鉴于此，HBase 可能比一些竞争对手发展得更快，而且经过了更充分的测试。
高血压