ios - 连续复制与一次性复制的成本(使用 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 复制的任何两个系统之间进行复制协议(protocol)[2].

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

让我们举一个人为的例子:每 10 秒窗口更新 1 次复制的源数据库，其中 TouchDB 数据库是目标。让我们进行 5 分钟的轮询与连续复制。为了简化调用计数，我们也将附件从图片。我们还假设设备具有持续的网络连接。

对于连续的情况，每 10s TouchDB 将在_changes 提要。这会导致 longpoll 连接关闭。TouchDB 然后运行更改，从源数据库；远程服务器上的一个或多个 GET 请求。尽管发生这种情况，TouchDB 必须打开另一个 longpoll 请求到 _changes。所以在五分钟内，你可能会得到对 _changes 的 30 次调用，加上获取文档和记录的所有调用检查点。

将此与每五分钟一次的一次性复制进行比较。你在一次 _changes 提要调用中接收 30 次更新的通知。TouchDB 实现了一个优化[3]，它将调用 _all_docs以 1 转的速度获取更新的文档，因此您可能最终得到一个调用以获取所有 30 个文档(在连续情况下不可能，因为您收到了一次零钱)。然后你有检查点文件记录。最多少于 5 个 HTTP 调用，最多大约三分之一连续的情况，因为您已经避免了额外的 _changes 请求。

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

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

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

但是，更改的更直接可见性的好处可能当然值得这种不确定性。