fatcache - Memcache on SSD

&#62; False positives from SHA-1 hash collisions are detected after object retrieval from the disk by comparison with the requested key.<p>I was curious why they would bother, but it seems this isn't quite accurate.<p>What happens is they first use 32 bits from the SHA-1 hash to find the hash bucket, then they scan for the full SHA-1 of the key. They do not check for actual SHA-1 collisions.<p>edit: Also on the subject of hashes, the readme suggests switching to MD5 as a possible way to reduce entry size. That is unnecessary; SHA-1 can be truncated to whatever size you're comfortable with.

If you find this interesting, you might also find this article in Communications of the ACM interesting:<p>Michael Cornwell: Anatomy of a Solid-State Drive<p>Communications of the ACM, Vol. 55 No. 12, Pages 59-63<p><a href="http://cacm.acm.org/magazines/2012/12/157869-anatomy-of-a-solid-state-drive/fulltext" rel="nofollow">http://cacm.acm.org/magazines/2012/12/157869-anatomy-of-a-so...</a><p>Alternative link in case the first is paywalled for people not on a university campus: <a href="http://queue.acm.org/detail.cfm?id=2385276" rel="nofollow">http://queue.acm.org/detail.cfm?id=2385276</a><p>It goes into quite some detail on how SSD storage works on a system level and how it differs from hard disks.

If you are willing to give up range scans and constrain yourself to fitting all keys in memory there is a lot you can do. See SILT (www.cs.cmu.edu/~dga/papers/silt-sosp2011.pdf) and Bitcask (downloads.basho.com/papers/bitcask-intro.pdf).<p>Since this is a cache I really dig skipping any kind of cleanup/compaction step for deleted/expired keys.<p>I played around with a similar thing except as a K/V store and the performance and density is pretty amazing. With a 64 byte key and 1.5k value (compressed from 2k) I was getting 85k inserts/sec and several hundred thousands reads/sec with a quad-core Sandy Bridge i5 and a 128 gigabyte Crucial M4 on SATAII.

&#62; False positives from SHA-1 hash collisions are detected after object retrieval from the disk by comparison with the requested key<p>Is that check really necessary?<p>To have <i>1 in a trillion</i> chance of having accidental SHA-1 collision they'd have to store 1.7*10^18 keys, and mere key index of that would require 54000 petabytes of RAM.

Curious, why not just use an mmapped file for the store a la varnish? If the file lived on the SSD you'd get in-memory caching for free from the OS.

So apparently inventing your own SSD caching system is all the rage? We already had flashcache from Facebook : <a href="https://github.com/facebook/flashcache/" rel="nofollow">https://github.com/facebook/flashcache/</a> And bcache : <a href="http://bcache.evilpiepirate.org/" rel="nofollow">http://bcache.evilpiepirate.org/</a><p>However this one isn't kernel-based, so it won't help your NFS server or your postgresql engine. On the other hand it's much easier to build.

The README says that memory is 1000s of times faster than SSD.<p>With that, how much faster is SSD over disk and then memory over SSD?

Cool idea, I believe aeorspike uses ssd's for key value store like this. Check out <a href="http://www.aerospike.com/performance/architecture/" rel="nofollow">http://www.aerospike.com/performance/architecture/</a> .

"Slab item chunk sizes" suggests they retained memcache's external fragmentation problem (if you mostly have big objects expiring, those slabs of memory won't ever be reused for storing small objects, or vice versa). On memcached with no persistence, you could recover from this by restarting (if you could withstand the availability hit), but what do you do once you're relying on long-lived state?

I believe go-memcached is faster than fatcache - <a href="https://github.com/valyala/ybc/tree/master/apps/go/memcached" rel="nofollow">https://github.com/valyala/ybc/tree/master/apps/go/memcached</a> . Will return with performance numbers soon :)

Cool, but what I was envisioning when I came up with the term "fat cache" over a year ago was client-side. This seems to be server side, unless I've misunderstood.<p><a href="http://news.ycombinator.com/item?id=3544522" rel="nofollow">http://news.ycombinator.com/item?id=3544522</a>

This is insane.<p>Awesome, useful, and cool, but insane.<p>I like it.