我想迁移一个现有的应用程序， 存储在关系数据库中的1000万条logging到CouchDB。 我喜欢CouchDB的东西是简单的复制和快速caching视图。 我不喜欢的东西是写入和视图创build的速度，这将是非常缓慢的1000万份文件。
我必须解决这些潜在瓶颈的一个想法是有三个CouchDB实例：
实例2从实例1复制而来。由于不会有任何使用实例2的应用程序，因此可以在不影响生产应用程序的情况下创build新的视图。
实例3从包含所有caching视图的实例2复制而来。
这是一个可行的解决scheme？
我相当肯定CouchDB不会复制视图caching（毕竟它们是caching），所以你不得不复制那些带外（这种错过点，国际海事组织）。
CouchDB对于写入负载可能不太好。 如果你的负载是重读的，我想你可以在每次插入/更新之后调用视图，这样视图总是被caching支持。
免责声明：我在几个站点使用CouchDB，但是几乎没有你正在谈论的大小。
我从来没有运行CouchDB，只研究它，所以不要把我的build议没有validation真实的…
首先，我强烈推荐阅读John P. Wood关于CouchDB生产使用经验的系列文章： http : //johnpwood.net/2009/06/15/couchdb-a-case-study/
接下来，当您说实例时，是否只有一个具有单个CouchDB实例的物理服务器？ 如果我们只谈3台服务器，我不认为通过分配不同的angular色来分配容量是最佳的。 我的直觉是让所有3台服务器保持一致，并加载完整的数据集，以便进行并行读取查询…？
如果只有3个服务器，我会考虑传统的RDBMS和传统的复制设置。 我怀疑CouchDB会为你带来这么小的计算能力吗？
另一件事，请仔细看看HBase，build立在Hadoop之上。 现在，Hadoop框架正在获得优秀的企业赞助，雅虎和Facebook都是大用户。 鉴于此，HBase的发展速度可能会比其他竞争对手更快，而且要经过更好的testing。
HTH