IndexedDB对象键：大小是否重要？

Question

我将在indexeddb对象存储中存储大量对象。 所有对象具有相同的结构，类似于{somekey: xxx, somevalue: yyy}。

对象键的长度是否影响存储数据的大小？ 例如，如果我更改结构为{s: xxxx, v: yyyy}，在当前浏览器中，应该期望在对象存储中获得更好的结果吗？

我无法在标准文档中找到任何关于此的信息，因此我猜测它取决于浏览器实现是否内部使用字典，并且我想了解当前如何实现以及减少存储对象键的大小是否值得优化。

- watsoup

Answer 1

是的，它会有影响。但至少对于相当大小的键来说，一个字符与10或20个字符之间的区别在性能上不会有任何影响，除非你处于非常大规模的情况下（数百万条记录）。大多数实现（包括我可以证明的Chrome）确实存储完整的对象，包括键名，但索引仅存储“keypath”一次。

这意味着{"foo": "bar"}可能需要大约12个字节的存储空间（每个字符串大约4个字节加上一些类型信息开销），但随后在“foo”上的索引只会存储“baz”。

{"foobarbaz": "helloworld"}可能需要大约23个字节的存储空间。实际上，在大多数情况下，您自己的数据应该超过键长度的开销，并且试图缩短键以节省几个字节是过早优化。

- alecf

---

谢谢您的回答，不过我的问题更多关于存储占用空间而非性能。例如，以您的示例为例，如果我将{"foobarbaz": "helloworld"}存储20次，当前的实现方式是使用约23字节 x 20，还是将键存储在字典中，并在结构中引用它（这意味着在所有对象中使用长键名不会对存储配额产生显著影响）？ - watsoup

抱歉，我觉得我可能给某个东西命名错误了。当我说“key”时，我指的是存储的结构化对象中的属性名称。 - watsoup

是的，我在谈论存储占用空间，通常情况下，至少在我所知道的实现中，对象被存储了20次。 - alecf