Initially, MySQL also supported BerkeleyDB, another KVS, but as for now they dropped the support.
From InnoDB's point of view, MySQL is just a client, as is HandlerSocket the author is using.
PostgreSQL's storage engine is much more closely integrated into the system and has no low-level API easily available from the outside.
How MySQL and InnoDB talk is very much a K<->V / row based relationship.
PostgreSQL supports C-based UDF so it might not be impossible, but I'm not sure whether PostgreSQL has a standard/documented/safe way to access to internal data structures from UDFs.
…and…
Yoshinori-san, very interesting! We use a similar technique for our site together Postgresql. We have our own Software ODBA that writes SQL, marshals the data and puts the marshaled Data into the PGsql-DB. All of our data is always in the memory if the Application is running. ODBA is written in Ruby. You can find it here: http://scm.ywesee.com/?p=odba/.git;a=summary
So maybe?
They said it was actually faster than other KVSes they tried. This was also a while ago.
Here it is: http://thinkvitamin.com/code/steve-huffman-on-lessons-learne...
It's called "Lessons Learned at Reddit", and mostly talks about building and deploying large-scale web applications (the technical, not business side of things.) Well worth watching (there's also a transcript.)
Speed.
Is the InnoDB storage engine that much superior compared to other products?
InnoDB is faster than MySQL over InnoDB.
Definitely yes, the author of the article already proved - web scale but reliable.
> No benefit for HDD bound workloads
Which is most workloads.
The author cites the expense of memory as the drawback to memcache. It's true, a large pool of dedicated memcache machines can be quite expensive. However, the given technology only works when the database fits in memory. If the database fits, then a cached subset of it certainly will fit as well. So memcache will only use a single server. One server is not a major expense compared to overhauling an application to marry it to a custom MySQL extension.
Also consider what happens if the database ever does grow beyond memory capacity. If you're using memcache, you might just need to add more cache servers. With HandlerSocket you'd have to... switch to memcache. Then add more cache servers.
This means no benefit over regular MySQL releases, not to say that MySQL doesn't have some nice features.
InnoDB can read/write in multiple threads - which is useful on RAID controllers which require concurrency to exploit all their throughput. Newer SSDs also like concurrent writes. Compare this to at least MongoDB which uses a single reader/writer thread.
Given the average RAM size on even an entry-level server (some 16 or maybe even 8 GB) and the average size of a database (same 8GB on http://musicbrainz.org/, the largest online music database), I wouldn't claim that it's "most workloads".
"Prepared Statement is still expensive in MySQL. It avoids SQL parsing, but it still has to open/lock/unlock/close tables, make query execution plans, etc."
(OT: under what circumstances are duplicate submissions allowed? There's nothing in the FAQ or the Guidelines.)
