7

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

谢谢你，保罗

4

1 回答 1

8

我认为您提到的问题是[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提要中收到一次更新。这会导致longpoll连接关闭。TouchDB 然后运行更改，从源数据库请求更新；远程服务器上的一个或多个 GET 请求。发生这种情况时，TouchDB 必须longpoll向_changes. 因此，在五分钟内，您可能会收到 30 次 _changes 调用，以及所有获取文档和记录检查点的调用。

将此与每五分钟一次的复制进行比较。您将在一次 _changes 提要调用中收到 30 次更新的通知。TouchDB 实现了优化[3]，它将调用 _all_docs 以获取 1-revs 的更新文档，因此您最终可能会通过一次调用来获取所有 30 个文档（在连续情况下不可能，因为您收到了单个更改）。然后你就有了要记录的检查点文件。最多少于 5 次 HTTP 调用，最多约三分之一的连续情况，因为您避免了额外的_changes请求。

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

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

另一个问题是，由于移动设备经常发生网络断开连接，连接会多久断开一次。TouchDB 的连续复制将在用户每次上线时重新启动（如果通过 _replicator 数据库添加）。这是不可预测成本的另一个来源。

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

于 2013-07-15T15:29:31.203 回答