Ключи объекта IndexedDB: размер имеет значение?
Я собираюсь хранить много объектов в хранилище объектов indexeddb. Все объекты имеют одинаковую структуру, что-то вроде {somekey: xxx, somevalue: yyy},
Влияет ли длина ключей объекта на размер хранимых данных? Например, если я изменю структуру на {s: xxxx, v: yyyy}следует ли ожидать лучшего следа в хранилище объектов с текущими браузерами?
Я не смог найти какую-либо информацию по этому вопросу нигде в стандарте, поэтому я полагаю, что именно реализация браузеров использует словарь для внутреннего использования или нет, и я хотел бы узнать о том, как он реализован в настоящее время, и о том, заслуживает ли он оптимизации уменьшить размер ключей объекта магазина.
1 ответ
Да, это повлияет на это. Но, по крайней мере, для клавиш разумного размера, один символ против 10 или 20 символов не будет иметь никакого значения в производительности, если вы не находитесь в очень большом масштабе (миллионы записей). Большинство реализаций (включая chrome, о котором я могу говорить) хранят полный объект, включая имена ключей, но индексы сохраняют "путь к ключу" только один раз.
Это означает, что {"foo": "bar"}, вероятно, занимает порядка ~12 байт для хранения (примерно 4 байта для каждой строки плюс некоторая дополнительная информация о типе, но последующий индекс для "foo" будет хранить только "baz").
{"foobarbaz": "helloworld"}, вероятно, занимает ~23 байта для хранения. На самом деле я ожидал бы, что в большинстве случаев ваши собственные данные должны затмевать издержки длины ключа, а попытка сократить ваши ключи для экономии нескольких байтов является преждевременной оптимизацией.