验证 IndexedDB (Int8Array) 中存储的数据的大小和类型

Question

我正在浏览器客户端中设置一个基于 IndexedDB 的虚拟文件系统。我的假设是，将类型化数组存储为值将是有效的；特别是，我通过 保存 8 kB 数据块Int8Array。我必须用什么方法来验证其有效性——实际使用的空间、实际的数据表示？

例如，在 Chromium 中，我可以看到似乎Int8Array得到了正确的保存。但“清除存储”页面显示的存储大小高得令人怀疑 - 91 kB - 尽管我编写的第一个测试文件大小仅为 40 kB（40096 字节分布在 5 个密钥上，加上 24 字节用于元数据密钥）。键是非常小的数组，包含短字符串路径和数字。所以看起来存储需要的时间大约是预期的两倍：

相比之下，我在 Firefox 中找不到有关使用量的任何信息，但存储浏览器仅显示值的“数组”类型，并且它们以 JSON 对象表示的效率非常低，尽管这可能只是显示问题：

ArrayBuffer一个相关的问题是，存储对象与Int8Array查看对象之间有区别吗？ArrayBuffer我尝试了两者，并且大小差异最小（如果我使用而不是作为传递给 IDB 的值，Chromium 使用 90.8 kB 而不是 90.9 kB Int8Array）。

Answer 1

第一：当然，只写入一个小文件可能会扭曲图像，因为数据库本身的开销会被打折。因此，我改为编写了一个 40 MB 的文件（现在ArrayBuffer直接使用），现在 Chromium 报告的存储使用量略低于 41 MB，确认数据存储相对紧凑。事实上，我可以看到实时更新的存储使用量在回到 41 MB 之前暂时较高，这表明也正在运行压缩/清理算法。由于 Firefox 无法显示 的数据使用情况file://，我通过 Web 服务器运行它进行测试，这里也使用了 41 MB 的空间。另一个令人惊讶的结果是，巧妙地存储一个Int8Array子数组实际上似乎也存储了整个支持ArrayBuffer内容。因此，虽然这些值是Int8Array(8192)在 Chromium 中报告的，但由于底层ArrayBuffer大小（在我的例子中为 64K），存储空间要大得多。从这个意义上说，最好直接存储ArrayBuffer实例以避免意外。顺便说一句，在这项任务中，Firefox 的速度比 Chromium 快大约 3 倍。两者的执行速度仍然非常慢（以 8 KB 为块存储 41 MB 的异步 I/O 分别需要 3 秒和 10 秒）。