http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Gotcha, Take a look at this solution, looks interesting... http://tirania.org/blog/archive/2011/Dec-19.html http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment11http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment11Tue, 12 Mar 2013 15:43:39 GMTIdo, The problem is that managed C++ won't work with Mono.http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment10http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment10Tue, 12 Mar 2013 15:36:27 GMTInstead of going the platform invoke way. Work with Managed C++ and the IJW. It will not only be easier to integrate but also perform better.http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment9http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment9Tue, 12 Mar 2013 15:34:48 GMTJDice, Sure, but that is something that you are going to have in _any_ ACID db with large values. http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment8http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment8Tue, 12 Mar 2013 12:32:10 GMTHere's something from the LevelDB benchmarks: LevelDB doesn't perform as well with large values of 100,000 bytes each. This is because LevelDB writes keys and values at least twice: first time to the transaction log, and second time (during a compaction) to a sorted file. With larger values, LevelDB's per-operation efficiency is swamped by the cost of extra copies of large values. http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment7http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment7Tue, 12 Mar 2013 02:22:04 GMTMatt - it's a rabbit hole - when you only need 10% of the functionality and you'd have to do 100% of the work to get that 10% into the other projects. Especially the LevelDB C api - do you really think they're going to take pull requests for this?http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment6http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment6Fri, 08 Mar 2013 15:41:15 GMTWhy write a new API? Why not contribute changes to the existing projects instead?http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment5http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment5Fri, 08 Mar 2013 15:18:26 GMTLeveldb handles concurrency for most operations across threads - which is what is required.http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment4http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment4Fri, 08 Mar 2013 14:46:49 GMT@James: yep, it does seem so "... The database file cannot be shared between multiple processes simultaneously..." source: http://blogs.msdn.com/b/windowssdk/archive/2008/10/23/esent-extensible-storage-engine-api-in-the-windows-sdk.aspx http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment3http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment3Fri, 08 Mar 2013 14:12:09 GMT@Rei - AFAIK Esent (as currently used by RavenDB) is also accessible from one process at a time.http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment2http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment2Fri, 08 Mar 2013 14:09:21 GMTReading the limitations list, do you really think it would be a good match for RavenDB? Specifically: Only a single process (possibly multi-threaded) can access a particular database at a time.http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment1http://ayende.com/161281/rob-s-sprint-the-cost-of-getting-data-from-leveldb#comment1Fri, 08 Mar 2013 12:26:52 GMT