【发布时间】：2016-07-06 20:38:15
【问题描述】：
我正在开发一个 iOS 应用程序，它将其数据存储在 sqlite3 数据库中。每个插入、更新或删除操作都在本地记录，然后推送到 iCloud，其他运行该应用程序的设备可以下载这些事务日志并执行其中的 SQL 命令，以保持所有运行该应用程序的设备同步。这工作得非常好。
我现在正在考虑优化流程，我突然想到，记录整个 SQL 命令会导致大量冗余数据被推送到云端并从云端拉取，这最终会导致更长的同步时间和更多的数据使用.
SQL 查询是非常可预测的（应用程序中只有一种插入、更新和删除格式）所以我正在考虑使用一个编码/解码例程，它将压缩 SQL 命令以存储在事务日志中，然后从日志中解压执行。
我发现的字符串压缩方法似乎不太适合 SQL 查询，所以我设计了自己的：
- 单字节标识 SQL 命令类型
- 应用程序中以数组为索引的表名和列名，并使用它们在数组中的索引位置对名称进行编码
- 表示列组的制表符分隔数字字符串和制表符分隔值（例如在 VALUES() 子句中）
- 编码检查列和值（用于更新或删除命令中的 WHERE 子句）
使用这种格式，我将一个 186 字节的示例查询压缩到仅 78 字节。这在数据传输速度和数据使用量方面具有明显优势。
我预见的缺点是它需要在客户端进行更多处理来对命令进行编码和解码。我想知道是否有人做过类似的事情并有什么建议可以提供。
为了更清楚地说明我的要求：一般来说，最好是尽量减少正在同步的数据量并增加客户端解释这些数据的负担，还是最好按原样同步数据和让客户按原样使用它？
【问题讨论】：
-
虽然你已经实现了大约 50% 的压缩，但是整体的数据量是相当微不足道的；当然这可能只是你的例子，我不知道你的应用需要同步多少数据。另一个选项是类似 zip 压缩
-
@Paulw11 - 感谢您的回复。我没有考虑过使用 zip 压缩。会有很多查询要同步，但数据值会非常小（例如，将一行从 0 更新为 1）。这就是为什么我想到将查询的最长部分（SQL 语法本身和表/列名）减少到可能的最短值并仅以完整格式发送变量本身。您是否认为压缩数据会导致更好的压缩，因为它还会压缩正在插入/更新的值？我想我可以同时做这两件事来获得更少的数据......
-
我不知道压缩是否会减少，但它应该能够在合理数量的文本上做到 50%。我想到 zip 的原因是标准库很容易获得，所以它的编码更少
-
鉴于大多数网络以数据包的形式传输数据，很可能即使从 186 字节减少到 78 字节也完全没有任何作用。两者都可以轻松放入单个典型数据包中。我怀疑你过度优化了。
-
@Paulw11 - 谢谢，我会研究一下 zip 选项。
标签： ios sql sqlite synchronization icloud