4 ms·
We need an async KV store: 1. Embedding of LevelDB or Kyoto. BitCask is terrific but has too slow a startup time for large data sets. 2. No range support. 3.
by jorangreef 15y ago
We need an async KV store:
1. Embedding of LevelDB or Kyoto. BitCask is terrific but has too slow a startup time for large data sets.
2. No range support.
3. No IndexedDB-style gargantuan-spec and setVersion versioning complexity. No versioning at all.
4. Just humble powerful KV.
5. Node-style callbacks.
6. Get/set/unset.
7. UTF8 keys.
8. ArrayBuffer byte-array values only - developers can layer any slow serialization/deserialization abstraction else on top.
9. Unlimited storage quota when requested by the app.
10. An option for the user to see how much storage the app is using so they can uninstall if it uses too much for their liking.
11. Fast.
12. True MVCC auto-completing read/write transactions (readers block writers in most IDB implementations, not MVCC) or cross-tab in-memory lock api.
After that we need an async BTree api.
- MatthewPhillips 15y agoIndexedDB doesn't have the setVersion stuff any more. New spec is much simpler just hasn't been fully implemented by any one yet.
- khuey 15y agoFirefox 11 has an essentially complete implementation of the IDB spec and it ships in two weeks. 10 definitely has the replacement for setVersion, but I don't remember what else missed 10.
- MatthewPhillips 15y agoFirefox has the most complete, there are certainly bugs though. For example I've had a lot of problems with multiEntry.
- khuey 15y agoCan you file bugs, or email me testcases at <my username>@mozilla.com? We definitely want to get this stuff right :-)
- forgotusername 15y agoSo you're basically asking for something like jQuery for IndexedDB (which could probably be written on top in a few 10s of lines of JavaScript). Baking a barebones API into the browser when a more powerful one has already been implemented doesn't make sense. Similarly for the WebSQL apologists, there's no reason <50kb of JavaScript couldn't provide a fully featured SQL engine on top of IndexedDB - IndexedDB implements most of the hard work (indexes, transactions, the container itself) already.
- huggyface 15y agoWebSQL apologists? Could you point me to such a simple JavaScript library? When IndexedDB was anointed that was the argument -- that the benefits of WebSQL could simply be layered atop. So where is it?
- jorangreef 15y ago"So you're basically asking for something like jQuery for IndexedDB" No. To use your terminolgy, IndexedDB is like jQuery on top of LevelDB. We need just LevelDB without the IndexedDB overhead. Surprisingly, there are things you can do with LevelDB that you can't do with IndexedDB. It's too high a level of abstraction.
- csears 15y agoChrome is already using LevelDB as the backend for IndexdedDB. http://news.ycombinator.com/item?id=2526263 http://news.ycombinator.com/item?id=2526263 Which of your points does Chrome's implementation not satisfy?
- jorangreef 15y agoHave you compared raw LevelDB performance against IndexedDB in Chrome? IDB in Chrome may have LevelDB somewhere underneath but it lacks points 9,10,11,12. As far as I know it does not yet have true MVCC, no real concurrency for multiple readers and writers. Single-transaction-at-a-time. Readers block readers.