问题
From what I can understand Chrome imposes a "soft" limit of 5Mb on the size of data stored in localStorage and IndexedDB. There are a number of things here that are not clear to me
- What precisely is meant by "soft" in this context?
- Does this mean localStorage:5Mb + IndexedDB:5Mb?
- I have not hit the buffers yet but then I keep clearing out my browser stores as I develop my app. What happens when the limits are reached? An exception is thrown and needs to be caught?
- Would there be much mileage in compressing data prior to storage? This seems to offer an excellent route if data compression is worth doing.
Compression would come at the cost of loosing the benefits of being able seamlessly to store/fetch JSON in IndexedDB (though this can be made transparent to my app with little extra effort).
I'd much appreciate any guidelines with these issues.
回答1:
Here are the listed answers of your doubts:
- Google Chrome has the quota of 5 MB. Here is the link to the specification - http://developer.chrome.com/extensions/storage.html#property-local-QUOTA_BYTES. Soft limit means it is the default quota, you can ask the user for his permission for more disk-space.
- Quotas for localStorage are different from IndexedDB - here is the link for disk-space quota for IndexedDB - https://stackoverflow.com/a/20675480/867629
When the localStorage reaches 5MB Google Chrome produces an error in the javascript console log:
Uncaught Error: QUOTA_EXCEEDED_ERR: DOM Exception 22
I haven't tried compression with locallStorage, so no idea about that.
回答2:
I wrote up a fiddle to examine what happens when the soft storage limits are breached - and also to test the utility of compressing what gets stored. Here is the fiddle
Local Storage Test
I have used the compression routines here for the test. The actual compression is easily done
var compr = LZString.compress(uncompr);
Notes
- The test need some time to execute so be patient!
- To increase the size of the stored data just increase maxTimes
- Compression works - very well indeed. However, as the tests will demonstrate, it can only realistically be used when storing relatively small (order of a few kb at the most) strings. For longer strings the compression itself takes too long and is liable to make your app unresponsive. I suspect that it would be better to question the need to store excessively long strings than to compress them.
- I use this technique for storing locally displayed HTML documents in localStorage and to store a range of configuration data objects in an IndexedDB database.
- Compressing data stored in IndexedDB means you loose the seamless storage/retrieval of JS objects that it offers. However, this can be dealt with easily via a simple wrapper.
来源：https://stackoverflow.com/questions/20756164/indexeddb-localstorage-storage-limits