71–80 of 82 posts
Anyone manage to compile this on OS X?
Was really psyched until I saw --std=c++0x in the Makefile. What 0x features does leveldb depend on, and can those dependencies be realistically removed?
The use of c++0x should be limited to the small AtomicPointer class in port_posix.h. The class uses for its implementation. If you can provide a different implementation of "acquire store" and "release load" for your architecture, you should be all set without the need for c++0x. I suspect that you may find suitable code in the chromium source code. See leveldb's port_chromium.h.
Anyone manage to compile this on OS X?
This could be great news for iOS. AFAIK, this is the first K/V DB that could be built for iOS (c++) and has a free license that is compatible with the AppStore (Tokyo Cabinet uses LGPL and the author has shown no interest to me in adding a static linking clause, Berkeley DB requires an expensive commercial license, etc).
What advantages does this have over the built-in SQLite?
The implementation seems to use Log-Structured Merge Trees. The only paper on this data structure seems to be: http://goo.gl/CVF1l This paper is poorly written and quite honestly not useful to implement an LSM tree. Does anyone know of a better paper than this one?
Earlier quoted context omitted.
Did you consider fractal trees? http://tokutek.com/presentations/bender-Scalperf-9-09.pdf
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-...
The implementation seems to use Log-Structured Merge Trees. The only paper on this data structure seems to be: http://goo.gl/CVF1l This paper is poorly written and quite honestly not useful to implement an LSM tree. Does anyone know of a better paper than this one?
Read "Cache-Oblivious Streaming B-trees" http://supertech.csail.mit.edu/cacheObliviousBTree.html It' LSM with faster searches.
@sghemawat: Are you planning on implementing atomic CAS operations?
We have no such plans. The library is designed so that concurrency control is outside its scope. If I needed it for an application, I might consider using some application level code that looks like: bool CAS(db, key, oldvalue, newvalue) { lock some mutex; read key's value from db; bool result = (value == oldvalue); if (result) write key=>newvalue to db; unlock; return result; } This should be not much slower than an…
Earlier quoted context omitted.
Read "Cache-Oblivious Streaming B-trees" http://supertech.csail.mit.edu/cacheObliviousBTree.html It' LSM with faster searches.
Thanks for the pointer. Are there any known open-source implementations of the same?
Note that this is not a database server , like Redis or Memcached. This is a database library , more along the lines of sqlite. In particular: "There is no client-server support builtin to the library. An application that needs such support will have to wrap their own server around the library" and only one process can access a database a time.