做couchdb视图复制？

我不是指存储在_design docs中的视图源(那些复制,因为它们只是文档).我的意思是视图结果(计算的btree)也会复制,或者只是复制常规文档(这就是我现在理解的方式).

有问题的情况是:
流量飙升,我想提出一个临时服务器,并将一部分数据集复制到新服务器上.已经在旧服务器上计算了那些(要复制的)文档的视图,因此不需要在新服务器上重新计算...所以我希望那些旧的计算结果与文档的一部分一起转移.

另一种情况是使用后端群集来计算复杂视图,然后将这些结果复制到实际受用户请求影响的一堆前端服务器上.

正如Till所说,结果没有复制.有关更多详细信息,您实际上不希望它们被复制.您应该记住的一般CouchDB范例是每个安装都被视为一个独立的节点 - 这就是_id,_rev和序列号如此重要的原因.这允许每个节点在不考虑任何其他节点的情况下工作:如果其中一个节点发生故障,所有其他节点将继续在世界范围内不小心处理.

当然,这引入了一些您可能不习惯的关于一致性的新考虑因素.例如,如果您有多个Web服务器,每个Web服务器上都有自己的CouchDB节点,并且这些节点在它们之间运行复制,以便每个实例保持最新,则节点之间将存在延迟.这是一个示例流程:

用户将更改写入Web服务器A.

用户向Web服务器B发出读取请求,因为您的负载均衡器确定B是更好的选择.用户获得他们的结果.

Web服务器A通过复制将更新的文档发送到Web服务器B.

如您所见,用户获得了其文档的先前版本,因为Web服务器B尚未了解更改.这可以用......来打败

坚持会话,以便他们的所有读取和写入都转到同一台服务器.这可能最终会击败您的负载均衡器.

将CouchDB节点从Web服务器移到自己的盒子上.如果你选择这个,那么你可能想看看couchdb-lounge项目(http://tilgovi.github.com/couchdb-lounge/).

您的用户是否真的关心他们是否会得到陈旧的结果？您的用例可能是您的用户不会注意到他们的结果是否反映他们刚刚做出的更改的用例.确保你真正从这项工作中获得了显着的价值.

干杯.