【发布时间】：2012-03-04 23:13:18
【问题描述】：
我的应用使用带有 FTS3 的 SQLite 数据库进行产品搜索。我正在尝试使用 SQLCipher 加密数据库，但这会导致数据库大小膨胀（7mb --> ~20mb）。
似乎没有一种很好的方法来压缩加密的 FTS SQLite 数据库。有人对此有什么建议吗？我必须缩小它以将应用程序保持在 20mb 3g 下载限制以下。
谢谢！
【问题讨论】：
【发布时间】：2012-03-04 23:13:18
【问题描述】：
与没有 SQLCipher 的数据库相比，没有理由使用 SQLCipher 的数据库会那么大。 SQLCipher 数据库的每个页面只使用 48 个字节的页面用于 IV 和 HMAC。因此，对于 1024 字节的页面大小，如果您有一个 7mb 的未加密数据库，则 SQLCipher 加密版本应该只有 7.34 mb。
更可能的解释是您的数据库因删除和插入而增长。如果数据库上没有启用auto vacuum，删除的行会继续占用空间。尝试在数据库上运行VACUUM 以回收空间。
如果清理数据库不能解决问题，这里有几个后续问题；
- 您确定 FTS3 索引不只是对文件大小负责吗？
- 您是否尝试过在非加密数据库中使用 FTS3 创建完全相同的架构和表结构，以比较文件大小以确保这实际上是 SQLCipher 的问题？ FTS3 的非加密数据库是 7 MB 吗？
- 如果对 1 和 2 的回答都是肯定的，您能否提供有关如何从未加密数据库转换为加密数据库的确切步骤？
要回答您的一般问题，SQLCipher 数据库可能无法很好地压缩。如果文件大小的增长实际上是 FTS3 而不是 SQLCipher 的结果，那么您可以考虑在应用程序上传送数据，然后在设备上构建 FTS3 虚拟表。
【讨论】：
-
您认为是因为我将 FTS 与 SQLCipher 结合使用吗？
-
从邮件列表后续发帖：
-
嗨，斯蒂芬 -- 感谢您的所有建议。应用程序大小的一些细分： 1. 未加密/使用 FTS 未压缩：21mb 2. 未加密/使用 FTS 压缩：7mb 3. 加密（SQLCipher）/使用 FTS 压缩：22mb 我认为问题不在于 SQLCipher --我只是不知道如何加密和压缩到应用程序中可用的大小。
-
啊，现在我明白了，7mb 是数据库的压缩大小。感谢您的澄清。我不认为此时有一个很好的压缩解决方案。您如何看待发送内容然后在设备上构建 FTS 索引？