连续复制的成本与一次性复制(使用TouchDB和Cloudant)

Question

我们有一个使用Cloudant作为远程服务器的应用程序.尽管如此,Cloudant并不完全兼容TouchDB以往经验的持续复制.因此,我们现在的替代方案是以固定频率手动触发一次性复制.尽管如此,我们想知道这种方法是否会比连续复制花费更多的钱,因为连续复制使用longpoll并且不需要经常查询服务器.换句话说,使用Cloudant作为目标的一次性拉动复制是否需要我们GET请求？

谢谢你,保罗

Answer 1

我认为你提到的问题是[1].Cloudant的复制与CouchDB 100%兼容.在这个例子中,TouchDB的日志表明iOS网络堆栈传递给不完整的JSON到TouchDB.目前尚不清楚在这种情况下谁应该因复制失败而受到指责.

[1] https://github.com/couchbaselabs/TouchDB-iOS/issues/241

对于成本问题,一次性拉动复制将导致_changes 每次发生时对Feed 进行GET ,以及复制所需的其他请求.此_changes请求将被视为针对您的Cloudant帐户的轻量级HTTP请求.

但是,这是否会因为更多或更少的请求总体而言取决于从远程服务器发出的更改的数量.

同样重要的是要记住,_changes相对于所涉及的其他呼叫的数量,呼叫的数量非常小(例如,自己获取更改的内容,特别是如果有许多附件).

虽然这个问题是TouchDB特有的,我提到了该代码库的具体行为,但这个答案处理了任何两个讲CouchDB复制协议的系统之间复制所涉及的请求[2].

[2] http://www.dataprotocols.org/en/latest/couchdb_replication.html

让我们举一个人为的例子:每10秒窗口更新1次到源数据库进行复制,其中TouchDB数据库是目标.让我们进行5分钟的调查,而不是连续复制.为了简化呼叫计数,我们还要从图片中取出附件.我们还假设设备具有恒定的网络连接.

对于连续情况,每10秒TouchDB将在_changesFeed中收到更新.这会导致longpoll连接关闭.然后TouchDB运行更改,从源数据库请求更新; 远程服务器上的一个或多个GET请求.在发生这种情况时,TouchDB必须打开另一个longpoll请求_changes.因此,在五分钟内,您最终可能会有30次调用_changes,以及获取文档和记录检查点的所有调用.

将其与每五分钟一次复制进行比较.您将在一个_changes Feed调用中收到30个更新的通知.TouchDB实现了一个优化[3],它将调用_all_docs来获取1转的更新文档,因此您可能最终只能通过一次调用来获取所有30个文档(在连续的情况下不可能,因为您收到了一个更改).然后你要检查检查点文件.最多只有少于5个HTTP调用,最多约为连续情况的三分之一,因为您已经避免了额外的_changes请求.

[3] https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm#performance

它归结为您期望对源数据库进行更新的频率.一次性复制可能会提供更平滑的价格曲线,因为您可以更好地控制所请求的数量.

另一个问题是,由于移动设备经常发生网络断开连接,连接的频率会下降.每次用户上线(如果通过_replicator数据库添加),TouchDB的连续复制将重新启动.这是不可预测成本的进一步来源.

然而,更直接的变化可见性带来的好处当然值得不确定.