SQLite数据库的高效同步 - 自动分块与来自Web服务的提示？

Question

摘要：分块数据以进行同步是否有任何众所周知的技术？块被认为是单独传输的数据块。

这可能是一个相当广泛的问题。建议时，我将开始更专业的主题。

我将设计/编写用于将Android平板电脑数据库（SQLite）与通过Web服务访问的中央数据库同步的代码。该机制应反映以下事实：

1. 它将用于各种应用。应用程序相当简单。无论如何，他们应该大多离线工作。
2. 数据量可以从小到大（最高可达平板电脑的技术限制）。
3. Web服务实现可能依赖于客户（即，应用程序不得要求重写Web服务;例如，可能存在保留SOAP而不是强制REST的历史原因。）
4. 在某些情况下，可以为应用程序创建特定的新Web服务（在客户站点使用相同的技术）。

问题的核心是如何最小化同步期间移动的数据的大小。问题不是关于如何实现异步下载。 （我正在考虑由Virgil Dobjanschi在Developing Android REST client applications中提出的实施技术。）

到目前为止，我找到了以下基本方法（不按特定顺序）：

1. 对少量数据进行强力攻击，即接收/发送所有内容，解决目标端的差异（下载时在平板电脑上，上传时在远程服务器上）。这里（比如说）整个数据库表可以看作是最大可能的数据块。
2. 使用修改日期（时间戳）作为数据记录，并根据上次同步中记住的日期仅同步较新的记录。对于添加和修改的记录，这很好;但是，必须对删除的记录使用一些附加机制。这里可以将单个记录视为可能的最小数据块。

以上是同步单个数据块。更现实的情况需要分块更多的记录。在这里，我认为块是一个可以单独传输的数据块。当传输失败时（即出于各种原因离线），只有失败和未传输的块必须同步。

我清楚的是，块应该具有一定的大小（形成一个大约10 kB的数据块）。

为了降低通信成本，构建的块包应保持不变，直到块的某些记录发生更改，添加或删除为止。无论是在中央服务器端还是在平板设备上构建，块都应该独立构建。

其他块不应受包含已更改数据的块的影响。这样，可以为双方的每个块计算SHA摘要，并且可以很容易地找到应该同步的块。

是否有关于如何确定块的标准技术，论文和示例？

由于

Answer 1

在我们的Rethync SDK框架（开源）中，我们采用了以下路径：每个对象的状态信息是一个不透明的字段（可以使用数据的时间戳或散列或一些独特的标记 - 左边供开发人员决定）。同步核心将此字段的值与保存的状态进行比较，然后决定是否需要上载，下载，删除对象等。

此方法要求在同步后保存状态（框架允许您保存状态），并将其用作在下次同步期间检测更改的基础。

我欢迎您检查Rethync，因为它完全符合您现在正在实施的内容。