All of these database systems have extremely different host requirements and write characteristics. Even SQLite and MySQL can be pretty different depending on the storage layer (SQLite can use BerkeleyDB)
The future isn't MySQL and spinning disks, the future is a tens of different databases that do things and handle reliability in a variety of ways. I know that complicates the issue even more, but my point would be that writing a halfway decent database is possible (or impossible, depending on your perspective) within a lot of this literature.
( Also, spinning disks even have abstractions since mostly you are using a RAID controller with a decent size of cache to alleviate random writes. )
What I meant with halfway decent database is one that can actually guarantee the data it committed is actually on the hard drive in a readable state, and that can sustain random writes at a rate close to the theoretical limit of the persistent storage device. I'm not judging any databases in particular. I'm asking how can I make a database that's as awesome as MySQL or Cassandra.
All these databases have already taught us a lot of what's in these articles, but one thing that isn't written about a lot is how they actually achieve high performance, not just in a theoretical way, but in a practical way. What system calls do they make, what schemes do they use to minimize seeks, how is the memory laid out. None of that high level "do we use Paxos of Raft", that's kids stuff.
Those papers have a lot of that information, but it's usually a bit buried.
> What system calls do they make
I think that's actually kind of out of scope for a paper, because already you are assuming an OS and a language. Many papers/articles assume neither.
> what schemes do they use to minimize seeks
Look for information on buffer management/buffer managers
> how is the memory laid out
Almost always in pages that correspond to disk blocks. Also it's dependent on lots of things (transactional model, index types, column vs row orientation, etc..) This is heavily tied into the buffer management stuff too.
Discussion between Postgres & Linux devs: http://lwn.net/Articles/590214/ & https://news.ycombinator.com/item?id=7521008
SSDs are much more complicated than spinning disks, so if anything the problem has gotten worse.
I for one would be very interested in that, although perhaps the deprecation of spinning disks has reduced the complexity of the issue.