我想迁移一个现有的应用程序，它大约有。1000 万条记录存储在 CouchDB 的关系数据库中。我喜欢 CouchDB 的一点是易于复制和快速缓存视图。我不喜欢的是写入和查看创建速度对于 1000 万个文档来说会非常慢。
我必须解决这些潜在瓶颈的一个想法是拥有三个 CouchDB 实例：
- 只写实例：这是主实例。我们的单点真理。这里只允许更新、插入和删除。此实例没有读取和视图。
- View creation only instance：仅用于创建和缓存视图。此实例上没有读取或写入。
- 只读实例：通过复制视图进行读取访问。
实例 2 是从实例 1 复制而来的。由于不会有任何应用程序使用实例 2，因此可以在不影响生产应用程序的情况下创建新视图。
实例 3 从包含所有缓存视图的实例 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 可能会比某些竞争对手发展得更快并且经过更好的测试。
高温高压
我相当确定 CouchDB 不会复制视图缓存（毕竟它们是缓存），所以你必须复制那些带外的（这有点错过了，IMO）。
CouchDB 可能不适合写入繁重的负载。如果您的负载毕竟是读取繁重的，我想您可以在每次插入/更新后调用视图，以便视图始终完全支持缓存。
免责声明：我在几个站点中使用 CouchDB，但远不及您所说的大小。