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

EN

我认为您提到的问题是1. Cloudant的复制与CouchDB 100%兼容。在本例中，TouchDB的日志表明iOS网络堆栈向TouchDB传递了不完整的JSON。目前还不清楚在这种情况下，谁应该为复制失败负责。

1

对于成本问题，一次拉取复制将导致每次发生时都访问_changes提要，外加复制所需的其他请求。此_changes请求将被视为针对您的Cloudant帐户的轻型HTTP请求。

然而，这在总体上是更多还是更少的请求取决于来自远程服务器的更改的数量。

同样重要的是要记住，_changes调用的数量相对于涉及的其他调用的数量非常小(例如，获取更改本身的内容，特别是如果有许多附件的话)。

虽然这个问题是特定于TouchDB的，并且我提到了该代码库的特定行为，但这个答案处理的是在使用CouchDB replication protocol2的任何两个系统之间进行复制所涉及的请求。

2

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

对于连续的情况，每10秒TouchDB将在_changes提要中接收一次更新。这会导致longpoll连接关闭。然后，TouchDB遍历这些更改，请求来自源数据库的更新；远程服务器上的一个或多个GET请求。在这种情况下，TouchDB必须向_changes打开另一个longpoll请求。因此，在5分钟的时间内，您可能会遇到30个对_changes的调用，以及获取文档和记录检查点的所有调用。

将其与每五分钟一次的复制进行比较。您将在一次_changes提要调用中收到30个更新的通知。TouchDB实现了一个optimisation3，它将调用_all_docs来获取更新后的文档，因此您可能只需一次调用即可获取所有30个文档(在连续的情况下，这是不可能的，因为您只收到了一个更改)。然后您就有了要记录的检查点文档。最多不到5个HTTP调用，最多是连续情况的三分之一，因为您已经避免了额外的_changes请求。

3

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

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

然而，从更直接的变化可见性中获得的好处可能肯定值得这种不确定性。