Re:LevelDB: a fast and lightweight key/value database library
by lisper on Sunday May 08, 2011 @03:19PM
(#2526527)
Did you consider fractal trees?
Re:LevelDB: a fast and lightweight key/value database library
by yingfeng on Monday May 09, 2011 @12:03AM
(#2527515)
fractal trees should have a faster read performance with leveldb with a comparable updating performance. There does not exist any open source solution for such structure, while we could hope that www.acunu.com might provide an open source solution for similary Stratified B-tree http://www.acunu.com/2011/04/log-file-systems-and-ssds-made-...
Re:LevelDB: a fast and lightweight key/value database library
by br1 on Monday May 09, 2011 @10:47AM
(#2528861)
Being in-kernel, acunu is very far from the lightness of LevelDB.
Re:LevelDB: a fast and lightweight key/value database library
by psaccounts on Sunday May 08, 2011 @04:34PM
(#2526670)
Is there a more useful technical paper on Fractal Trees? Better yet is there a open source implementation of the same?
Re:LevelDB: a fast and lightweight key/value database library
by jbapple on Sunday May 08, 2011 @10:44PM
(#2527346)
Cache-oblivious streaming B-trees:
http://supertech.csail.mit.edu/papers/sbtree.pdf
I don't know for certain any open-source implementation, but I have heard COLAs are used in HBase.
Re:LevelDB: a fast and lightweight key/value database library
by davidhollander on Sunday May 08, 2011 @06:49PM
(#2526898)
> difference in data structures
Always good to have more tools in one's arsenal in that case. I'll drop one of you a message if I write a Lua binding for it (using LuaJIT+embedded k/v for data services atm).
Re:LevelDB: a fast and lightweight key/value database library
by spullara on Sunday May 08, 2011 @05:18PM
(#2526748)
Have you looked at implementing CAS? It is the one thing missing for me to adopt it as a underlying store for my AvroBase API: http://www.javarants.com/2010/06/30/havrobase-a-searchable-e...
Re:LevelDB: a fast and lightweight key/value database library
by cmartella on Friday May 20, 2011 @04:14AM
(#2566909)
Could you please report about caching setup for random read test? was there any cache (a part of OS's) for either position/index lookup or payload? Or did you hit the disk without any caching of past operations?
thanks
However because of a fundamental difference in data structures (TokyoCabinet uses btrees for ordered storage; leveldb uses log structured merge trees), random write performance (which is important for our needs) is significantly better in leveldb. This part we did measure. IIRC, we could fill TokyoCabinet with a million 100-byte writes in less than two seconds if writing sequentially, but the time ballooned to ~2000 seconds if we wrote randomly. The corresponding slowdown for leveldb is from ~1.5 seconds (sequential) to ~2.5 seconds (random).