我利用couchdb / pouchdb将数据从服务器复制到移动设备(数据仅复制到移动设备的下游)。
由于我的数据集很大(大约100,000个文档),我尝试使用pouchdb中的紧凑功能,以确保磁盘上数据库的大小仍然很小,并且不会增长到不可管理的大小。
然而,我的测试显示手动压缩数据库对使用的磁盘空间没有影响。在我的测试中,我使用Chrome将100,000个文件从我的couchdb复制到pouchdb。
查看“ C:\ Users [USERNAME] \ AppData \ Local \ Google \ Chrome \ User Data \ Default \ databases [SERVER_URL] ”目录,我相信Chrome也会保存数据库,复制数据库后生成的文件大约为71MB。
然后,我只需在每个文件上增加一个值,就可以在couchdb中更新20,000个文档。我随后将这些更改复制到Chrome中的pouchdb。这导致数据库增长到81MB。在此之后手动压缩数据库不会影响 磁盘上pouchdb的大小。我已经执行了几次这样的操作,并且从未见过Chrome创建的pouchdb文件的大小减小。
测试摘要:
我创建了一个小示例应用程序来说明我的示例。你可以找到files here(请阅读readme.txt!)你可以用它来重现我的测试。
我是否误解了pouchdb中的压缩程序?我假设通过删除旧版本的文档(并且只保留叶子节点),我的pouchdb的磁盘大小在上面的示例中将保持相对大小。
或者我犯了一个愚蠢的编码错误? (对我来说并不罕见!)。
提前感谢您的帮助,
安德鲁。
更新 - 执行上述测试后,我决定使用小包来检索我的一个文档。我发现_revisions是一个包含4个元素的数组。这是我的数据库不断增长的原因所在 pouchdb跟踪文档的所有修订ID?如果我压缩我的数据库应该是这种情况吗?
答案 0 :(得分:1)
您似乎正在使用WebSQL适配器。 SQLite有一个奇怪的特性,即除非你做一个显式的VACUUM命令,否则它不一定要清理它的空间使用。我不知道VACUUM是否在WebSQL中可用,但您可能希望在压缩后尝试它以便真正清理数据库的大小。
如果该修复工作正常,我们可能也有兴趣在压缩时将VACUUM命令添加到PouchDB本身,这样您就不必手动执行此操作。 :)
答案 1 :(得分:1)
@nolan,谢谢你的指针。我在 pouchdb.cordova-sqlite.js 中的setup()函数中添加了以下代码行,这是sqllite的pouchDB适配器。
tx.executeSql("PRAGMA auto_vacuum = FULL");
有效!它确实释放了磁盘空间(我在iOS应用程序上查看了它)。感谢。