I want to use localStorage to store large amount of data(like 800GB), according to http://arty.name/localstorage.html and also I'm using Firefox, I changed my localStorage size and also the cache size. So the size isn't a problem. However, I write some jquery like the following:
$("a[href]").each(function(){
$(this).click(function(event){
localStorage.test += "somenewinformation";
...
If this localStorage.test already have large amount of data like 400GB, so the storing information step would be extremely slow. When I click on a link,will the jquery wait for me to finish the appending new information to localStorage.test or it will just go to the next page and information in localStorage.test will all lost or localStorage.test will just remain the old value? What I dont understand is whether a new thread will be generated to do this storing in background or not and closing browser in the middle will affect it or not.
Sorry about the messy description and thanks in advance!
You can't! The usual limit is 5 MB.
Some browsers such as Opera allow you to adjust the size, but this is purely dependent on the browser and is a user-initiated action, not a programmable one.
And even if you could remember that localStorage can only store strings, so anything else need to be stringified first. That together with this being an key-value storage array you will run into pretty poor performance at the end.
If you need large storage capacity, look into File API instead. This is made to work with large files (Blobs) and you can store anything as a Blob.
800 Gb is a large size and File API can only work as fast as the file system (at best, more likely a bit slower as it is sandboxed, ie. not a pure file system).
More about File System API (Note: discontinued as of 4/2014):
http://www.w3.org/TR/file-system-api/
Tutorial:
http://www.html5rocks.com/en/tutorials/file/dndfiles/
Blob:
https://developer.mozilla.org/en-US/docs/Web/API/Blob
Update As the Filesystem API has been discontinued there are essentially only two options left (besides from storing data to the server):
Indexed Database API aka Indexed DB (recommended)
Web SQL (deprecated but still supported in browsers such as Safari)
Also these are initially limited in size by the browser. It is possible to request a larger quote which the user is asked to accept.
See more details about this API here:
http://www.w3.org/TR/IndexedDB/
There is LargeLocalStorage which provides a cross-browser way to storage large amounts of data locally. You can store binary data or strings.
LargeLocalStorage uses the FilesystemAPI on Chrome, IndexedDB in IE and Firefox and WebSQL in Safari.
Related
I've got an application where i'd like to share data across windows. The data will almost always be less than 5MB but in some cases it may be 7MB or more. In order to share this data across windows I need to write the data to local storage in chunks, and once the data has been collected, replace it with the next chunk to be collected.
My question is. How do I calculate this with javascript? Not only do I need to calculate the byte size of the data, but I also need to calculate whatever head I will give the "packet" of data, so when it's received it can be concatenated to the right (incomplete) "packet" in the other windows. In local storage how do I figure out,
A. How much data is available?
and
B. How much space will my data take up?
There is no standard size in the spec. This StackOverflow answer shows two quotes, the defaults appear to be 5mb for most browsers, and 10mb for Internet Explorer. The second quote is important, as it says that each browser gives the user the ability to customize this limit. There is no way detect if you are approaching the limit.
Per the W3C spec the setItem method will throw a QuotaExceededError if you exceed the browser's quota.
Regarding the size of the data stored, what you are storing is strings. You can get to 5mb, or 10mb, sure, but that's a huge amount of data. To get perspective, look at a text file that is 5mb large. Although that may not be an accurate depiction of how much text you could store using localStorage, it would still be massive! To either end, when implementing code that uses setItem, be sure to check if the exception is thrown.
I've got a web app which gets a couple dozen items at boot. All these items are JSON and are smaller then 1kb.
Now there are a number of storage options as seen in the Question.
I was thinking of just storing these objects inside a variable in the browser JS. I don't really see why I would want to use any of these browser storages?
So what would be reasons to use any of the browser-based storage instead of a variable inside JS.
Could be that from a certain data size it is preferable to use browser storage, e.g. from 100kb onwards it's better to not use a JS variable.
var myModel = {}
NOTE
Every time the user enters the app he will get fresh content from the server. The content is too realtime for caching.
`
localStorage , globalStorage and sessionStorage:
These features are ready in browsers that have implemented the "Web Storage", they all refer to a kind of HashMap, a map between string keys and string values. but the life is different. once the active page is closed sessionStorage would be cleaned but the localStorage is permanent.(MDN DOM Storage guide)
There is a point about globalStorage, which is its being obsolete since Gecko 1.9.1 (Firefox 3.5) and unsupported since Gecko 13 (Firefox 13), since then we should use localStorage. the difference between these 2 was just the HTML5 scope support(scheme + hostname + non-standard port).
These could be useful for you to:
-Share your objects between your different pages, in your site.
-Offline programming.
-Caching large object
-Or whenever you need to a local persistent storage.
IndexedDB:
IndexedDB is useful for applications that store a large amount of data (for example, a catalog of DVDs in a lending library) and applications that don't need persistent internet connectivity to work (for example, mail clients, to-do lists, and notepads)
based on this quote from MDN you can easily find your answer out, regarding using IndexedDB, if you don't know whether IndexedDB is useful for you or not, just answer these questions:
Do you store a large amount of data on client? if yes, so consider using it.
Does your app need to be offline enabled? if yes, so consider using IndexedDB.
Does your app need to a persistent internet connectivity? If yes, it stays still an option, based on the other factors.
So other than working offline as far as you don't need it, I guess, because as you said:
The content is too realtime for caching.
These have some features like sharing objects, and managing large amount of data, which you should be the one to decide.
localStorage and sessionStorage are solving a caching problem; think of them as cookies. You've said you don't want caching, so you can ignore them.
JavaScript objects behave basically like O(1) lookup tables (see How is a JavaScript hash map implemented?, and make sure you read both the top two answers, as both have something useful to say), and there is no maximum memory limit that I am aware of, or a point where another solution becomes a better choice
The only reason I can think of that you should bother with the extra step of inserting the data in an IndexedDB is if you need O(1) lookups on a field that is not the object key you are using.
Inorder to reduce server load, I would like to bring many task into client side. There is no clear information about browser memory limit and its recycling ... Just like PHP session is there any clean function or any limit of storage size for browsers?
Basic javascript variables will last only for the duration of the page
For more persistent variables, use either sessionStorage (these will last until the user closes their browser/tab) or localStorage (these will last "forever"/until the user clears their personal data)
https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage
Note that the above are available in all modern browsers, but notably not in IE<=7, in which case you would need to use cookies as a storage mechanism. However, if you need that, you can probably find a library that will take care of the nitty gritty details
I believe the maximum storage is domain based...i.e. each domain gets x amount of data.
But what about when a user switches between browsers?
Do they use two completely separate spaces and similarly separate maximum data amounts.
Secondly,
is localStorage.a in Browser 1 different from localStorage.a in Browser 2?
Similar SO
What is the max size of localStorage values?
HTML5 localStorage size limit for subdomains
Reference
W3
Mozilla
Wikipedia
Browsers vendors won't implement shared localStorage. Each browser that supports localStorage will have an independent instance of however it has been implemented.
Put simply, yes they do. It is browser specific/domain specific storage.
I need to fetch some chunks of data in a Javascript loop. The pieces will probably be small between 2 and 20 Kb but being in a loop I need speed. I can get these pieces of code from local storage:
var code = localStorage.getItem(myVar);
or even from jQuery .data()
var code = $('#myDiv').data(myVar);
I was unable to find info on localStorage or sesionStorage speed or if I can cache these values into memory.
What would be fastest and better to use?
Thanx
http://www.html5rocks.com/tutorials/speed/quick/#toc-databases
As a rule of thumb: The more data you have, the more appropriate the client-side databases become. To find the break-even point, you'll have do do some testing i suppose.
Webstorage is perfect for chunks of data with that dimension and it' really fast retrieving data from the browser. You don't need any cache, because the data are on the browser, you can rather use those data with offline applications as well.
I would suggest using pure JS, as it doesn't add any overhead or any dependencies and the WebStorage API are quite straightforward.
If you wanna know more about WebStorage, try to read my article