连续复制的成本与一次性复制（使用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的GET 每次发生时都会提供，以及需要的其他请求 复制。此_changes请求将被视为灯光 针对您的Cloudant帐户的HTTP请求。

但是，这是否可以作为更多或更少的整体请求 取决于从远程服务器发出的更改数量。

记住_changes来电的数量非常少，这一点也很重要 相对于所涉及的其他呼叫的数量（例如，获得 变化本身的内容，特别是如果有很多变化 附件）。

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

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

让我们举一个人为的例子：每10秒窗口更新1次 用于复制的源数据库，其中包含TouchDB数据库 是目标。让我们进行5分钟的调查，而不是连续复制。 为了简化呼叫计数，我们也可以使用附件 图片。我们还假设设备具有恒定的网络连接。

对于连续的情况，每10秒TouchDB将收到一次更新 _changes Feed。这会导致longpoll连接关闭。 TouchDB然后运行更改，请求更新 源数据库;远程服务器上的一个或多个GET请求。而 发生这种情况，TouchDB必须打开另一个longpoll请求 到_changes。因此，在五分钟的时间内，你最终也许会结束 30次调用_changes，加上所有调用来获取文件和记录 检查点。

将其与每五分钟的一次性复制进行比较。你 在一个_changes Feed调用中收到30个更新的通知。 TouchDB实现了一个优化[3]，它将调用_all_docs 获取1- revs的更新文档，因此可能最终只有一个 打电话来获取所有30个文件（在连续案例中不可能作为 你收到了一个改变）。然后你就有了检查站文件 记录。最多只有不到5个HTTP调用，最多约为三分之一 连续案例，因为您已经避免了额外的_changes次请求。

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

归结为您对源的更新频率 数据库。一次性复制可能会提供更平稳的价格 曲线，因为你可以更好地控制你的请求数量。

另一个问题是，由于这种情况，连接的频率会下降 网络断开连接定期发生在移动设备上。 TouchDB的连续复制每次都会重新启动 用户上线（如果通过_replicator数据库添加）。这是一个 进一步造成不可预测的成本。

然而，更直接的变化可见性的好处可能 当然值得不确定。