Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best practise of using localstorage to store a large amount of objects

Currently I'm experimenting with localStorage to store a large amount of objects of same type, and I am getting a bit confused.

One way of thinking is to store all the object in an array. But then for each read/write of a single object I need to deserialise/serialise the whole array.

The other way is to directly store each object with its key in the localStorage. This will make accessing each object much easier but I'm worried of the amount of objects that will be stored (tens of thousands). Also, getting all the objects will require iterating the whole localStorage!

I'm wondering which way will be better in your experience? Also, would it be worthwhile to try on more sophisticated client side database like PouchDB?

like image 986
Wudong Avatar asked Jul 01 '15 09:07

Wudong


People also ask

Is it good practice to store data in local storage?

In basic terms, local storage enables developers to store and retrieve data in the browser. It is critical to understand, though, that using localStorage as a database for your project is not a good practice, since data will be lost when the user clears the cache, among other things.

What is the maximum size limit that localStorage allows?

It is limited to about 5MB and can contain only strings. Because it is tab specific, it is not accessible from web workers or service workers. LocalStorage should be avoided because it is synchronous and will block the main thread. It is limited to about 5MB and can contain only strings.


2 Answers

If you do not want to have a lot of keys, you can:

  • concat row JSONs with \n and store them as a single key
  • build and update an index(es) stored under separate keys, each linking some key with a particular row number.

In this case parsing rows is just .split('\n') that is ~2 orders of magnitude faster, then JSON.parse.

Please, notice, that you possibly need special effort to syncronize simultaneously opened tabs. It can be a challenge in complex cases.

localStorage has both good and bad parts.

Good parts:

  • syncronous;
  • extremely fast, both read and write are just memcpy – it‘s 100+Mb/s throughput even on weak devices (for example JSON.stringify is in general 5-20 times slower than localStorage.setItem);
  • thoroughly tested and reliable.

Bad news:

  • no transactions, so you need an engineering effort to sync tabs;
  • think you have not more than 2Mb (cause there exist systems with this limit);
  • 2Mb of storage actually mean 1M chars you can save.

These points show borders of localStorage applicability as a DB. LS is good for tasks, where you need syncronicity and speed, and where you can trim you DB to fit into quota.

So localStorage is good for caches and logs. Not more.

like image 144
ermouth Avatar answered Sep 23 '22 22:09

ermouth


If you want something simple for storing a large amount of key/values, and you don't want to have to worry about the types, then I recommend LocalForage. You can store strings, numbers, arrays, objects, Blobs, whatever you want. It uses IndexedDB and WebSQL where available, so the storage limits are much higher than LocalStorage.

PouchDB works too, but the API is more complex, and it's better-suited for when you want to sync data with CouchDB on the server.

like image 45
nlawson Avatar answered Sep 26 '22 22:09

nlawson