我在 CouchDB 的同一个文档中存储了大约 2500 张图像作为附件。这些图像在硬盘驱动器中大约占用 15MB,结果 CouchDB 大约为 17MB。
当我通过 PouchDB 将此文档推送到我的客户端时,我看到生成的数据库超过 40 MB。我按照以下步骤进行了一些测试:
这是结果:
number of attached files | Total size (KB) in HD | Inc | Size in Indexed DB | Inc
17 129 207
27 168.2 39.2 267 60
37 219.6 51.4 335 68
47 275.5 55.9 414 79
57 327.7 52.2 493 79
67 384.9 57.2 579 86
77 428.5 43.6 654 75
所以,似乎:
图像在 CouchDB 和 PouchDB 中都有 content_type:image/png 。我知道这应该可以防止将它们存储为 base64。我对么?
有没有人更早看到这个?有没有人能够解决它?
当目标是在 iOS 50MB 空间限制内适合应用程序时,这是一个大问题。
编辑
我继续检查 pouchDB 与原始文件中一些图像的大小:
所以我认为在 PouchDB 中存储附件时大小的增加不是来自任何控制数据(至少它不相关),而是来自二进制文件在浏览器 IndexedDB 中的存储方式(我使用 Chrome 进行这些计算)。
那么,为了避免 PouchDB 中二进制大小的增加,还需要做些什么吗?
最佳答案
一个很好的问题,但答案取决于您使用的适配器,从描述中不清楚。
编辑:刚刚意识到你确实说过 Chrome,但我保留了后代的原始答案:)
我猜你是在 Chrome 中测试。因此,您看到性能不佳的原因是我们必须将所有内容存储在 base64 中作为解决方法( source )。
从好的方面来说,那个 Chromium 错误非常活跃(最后一条评论是 48 小时前),所以大概 Chrome 团队正在处理它,并将很快发布修复程序。当他们这样做时,PouchDB 会自动检测到 blob 支持可用并开始使用它。
更新: Chrome 团队修复了这个问题,从 Chrome v43 开始,PouchDB 支持 Blob。 :)
关于couchdb - 袋 DB : database size,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23724331/