Лучшая практика использования localstorage для хранения большого количества объектов

В настоящее время я экспериментирую с localStorage для хранения большого количества объектов одного типа, и я немного запутался.

Один из способов мышления — хранить все объекты в массиве. Но тогда для каждого чтения/записи одного объекта мне нужно десериализовать/сериализовать весь массив.

Другой способ — напрямую хранить каждый объект с его ключом в localStorage. Это значительно упростит доступ к каждому объекту, но меня беспокоит количество объектов, которые будут храниться (десятки тысяч). Кроме того, для получения всех объектов потребуется повторение всего локального хранилища!

Мне интересно, какой способ будет лучше в вашем опыте? Кроме того, стоит ли попробовать более сложную клиентскую базу данных, такую ​​как PouchDB?


person Wudong    schedule 01.07.2015    source источник
comment
Есть ли шанс, что ваш проект может собрать более 5 МБ данных в автономном режиме? Если это так, то вам определенно нужен PouchDB и его адаптеры WebSQL и IndexedDB (хотя для очень старых браузеров все еще есть опция localStorage)   -  person Angel Paraskov    schedule 01.07.2015
comment
Я знаю об ограничении в 5 МБ на локальном хранилище. Пока все хорошо, поэтому я не слишком беспокоюсь об этом. PouchDB — это более 100 тыс. зависимостей. Я действительно не хочу добавлять это, если это действительно поможет.   -  person Wudong    schedule 01.07.2015
comment
Что ж, если место не является проблемой, то почему бы не перейти на PouchDB и не думать о том, как хранить данные и как их поздно обновлять. Пусть PouchDB API позаботится об этом вместо вас. У вас также есть очень хорошая поддержка стиля map/reduce CouchDB или даже плагинов SQL, GQL и Mongo для написания запросов в стиле SQL, Google QL или Mongo. Удачи   -  person Angel Paraskov    schedule 01.07.2015
comment
PouchDB составляет ~ 50 КБ min + gz, тогда как LocalForage составляет ~ 20 КБ. :)   -  person nlawson    schedule 02.07.2015


Ответы (3)


Если вы не хотите иметь много ключей, вы можете:

  • объединить строки JSON с \n и сохранить их как один ключ
  • построить и обновить индекс(ы), хранящиеся под отдельными ключами, каждый из которых связывает некоторый ключ с определенным номером строки.

В этом случае синтаксический анализ строк составляет всего .split('\n'), что примерно на 2 порядка быстрее, чем JSON.parse.

Обратите внимание, что для синхронизации одновременно открытых вкладок могут потребоваться особые усилия. В сложных случаях это может быть проблемой.

localStorage имеет как хорошие, так и плохие стороны.

Хорошие части:

  • синхронный;
  • очень быстрый, и чтение, и запись — это просто memcpy — это пропускная способность 100+ Мбит/с даже на слабых устройствах (например, JSON.stringify вообще в 5-20 раз медленнее, чем localStorage.setItem);
  • тщательно проверены и надежны.

Плохие новости:

  • никаких транзакций, поэтому вам нужны инженерные усилия для синхронизации вкладок;
  • считайте, что у вас не более 2Мб (потому что существуют системы с таким ограничением);
  • 2 МБ памяти на самом деле означают 1 миллион символов, которые вы можете сохранить.

Эти точки показывают границы применимости localStorage в качестве БД. LS хорош для задач, где вам нужна синхронность и скорость, и где вы можете урезать свою БД, чтобы она соответствовала квоте.

Так что localStorage хорош для кешей и журналов. Не больше.

person ermouth    schedule 08.07.2015

Если вам нужно что-то простое для хранения большого количества ключей/значений и вы не хотите беспокоиться о типах, я рекомендую LocalForage. Вы можете хранить строки, числа, массивы, объекты, BLOB-объекты и все, что захотите. Он использует IndexedDB и WebSQL, где это возможно, поэтому пределы хранения намного выше, чем у LocalStorage.

PouchDB тоже работает, но API более сложный и лучше подходит для случаев, когда вы хотите синхронизировать данные с CouchDB на сервере.

person nlawson    schedule 02.07.2015

Я лично не использовал localStorage для управления таким количеством элементов.

Однако шаблон, который я обычно использую для управления данными, заключается в загрузке полной информационной базы данных в объект javascript, управлении ею в памяти во время процесса и повторном сохранении в localStorage после завершения процесса.

Конечно, этот шаблон может не соответствовать вашим потребностям, в зависимости от спецификаций вашего проекта.

Если вам нужно постоянно сохранять данные, доступ к данным может стать проблемой, и поэтому, вероятно, использование некоторого типа доступа к небольшой базе данных является лучшим вариантом.

Если ваш объем данных исключительно велик, также может возникнуть проблема с управлением им в памяти, однако, в зависимости от модели данных, вы сможете создать для него эффективные структуры, которые позволят вам загружать и сохранять данные именно тогда, когда это необходимо. .

person Bardo    schedule 01.07.2015