Of course there's plenty of literature on individual components, but a holistic view would be fun to read.
I suppose you could read sqlite or postgres code... but that doesn't fit well on a Kindle. :)
Of course there's plenty of literature on individual components, but a holistic view would be fun to read.
I suppose you could read sqlite or postgres code... but that doesn't fit well on a Kindle. :)
It's a sqlite clone from scratch.
Once you can quickly find a thing with some key, any degree of structure and complexity is possible from that point. Column-based, row-based, document-based, etc. All are possible to build on top of K-V. Might not be the most optimal solution, but it is a very accessible path in my experience. You can start defining types like Table, Column, Row, Document, etc. which all leverage this idea that you can trivially refer to another thing by some identifier. For instance, Table.FirstRowId and Table.LastRowId could be used to refer to the logical extents of a collection of rows that might be linked together both ways (e.g. Row.PreviousRowId, Row.NextRowId).
Like, If I wanted to, I bet I know I could create the server, connection manager, query parser, optimizer, WAL, storage... and maybe I will, but would just be fine to read about someone else doing it.
I spend enough time coding as it is. :)
Database Internals: A Deep Dive into How Distributed Data Systems Work https://www.amazon.com/_/dp/1492040347