davisp commented on issue #496: Couchdb 3287 pluggable storage engines
URL: https://github.com/apache/couchdb/pull/496#issuecomment-297745272
 
 
   Also, I forgot to link out to the first complete alternative storage engines.
   
   https://github.com/cloudant/couch_ngen
   
   The couch_ngen engine (its a super terrible name I know) was one that I 
wrote fairly quickly just to try and prove that the API wasn't artificially 
restrictive. The biggest thing here is that I'm using multiple files for a 
single database to try and make things like compaction faster. This is the same 
general shape as the existing legacy engine with a few tweaks that we've 
considered over the years but never actually tried to implement due to upgrade 
concerns. This also uses a NIF for file I/O with dirty schedulers (thus your 
Erlang VM needs to have dirty schedulers enabled to run this engine). Initial 
benchmarks show this engine to be significantly faster than the legacy engine 
at the local node interface. Unfortunately those gains don't show up nearly as 
well at the clustered interface (so we've got more work to do there :)
   
   https://github.com/cloudant-labs/lethe/tree/initial-branch
   
   Lethe is the first engine written by !me. This work is by @chewbranca trying 
to investigate the storage engine API by actually using it to write a storage 
engine. Lethe is an ephemeral/in-memory storage engine. Think ramdisk database 
thing. Its not been benchmarked to the best of my knowledge but last I heard it 
was passing the storage engine test suite and could run most of the existing 
test suite (it doesn't support attachments which are optional in the API).
   
   There are some other obvious candidates for storage engines as well that 
I've not tried (on purpose to let others play with something new and 
interesting). LevelDB/RocksDB, LMDB, PostgreSQL, SQLite, Bitcask, etc all come 
to mind as obvious things to play with. Also something I've been contemplating 
is writing a custom storage engine in C that is behaviorally similar to the 
existing code but hopefully significantly faster (though remember if speed is 
your goal we've got more work to do in the clustering layer :)
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to