
Dagoba: an in-memory graph database (2016) - jxub
http://aosabook.org/en/500L/dagoba-an-in-memory-graph-database.html
======
marknadal
This is a really, really great article. Shame it didn't get on HN 2 years ago.

For anyone interested in the history of databases, as the author eluded to, it
began with graph databases first (called Navigational Databases), and then SQL
came in and actually ruined the approach and performance (despite people
thinking SQL databases were designed for storage constraints, that didn't come
until later after the relational model had been more developed). If you want
to learn more about this history, I did a talk out in Italy (later recorded on
a web cast) about it here:
[https://vimeo.com/208899228/b9bc9eaaa4](https://vimeo.com/208899228/b9bc9eaaa4)

~~~
chrisweekly
"eluded" (escaped/avoided) -> "alluded [to]" (referenced)

------
jeffschofield
Here's a link to this article with working source on GitHub:
[https://github.com/dxnn/dagoba](https://github.com/dxnn/dagoba)

Really useful to see it all put together.

------
Ozlone
This is an excellent article -- not just technically, but tonewise as well;
kudos to the author.

------
easytiger
> Fortunately, we're building an in-memory database, so we don't have to worry
> about any of that!

If I wanted to do something in memory, I'd just use data structures in my
process. Not so much a database if there is no persistence.

~~~
JulianWasTaken
Haven't read the article yet, about to, but that sounds a bit naive.

In-memory is not exactly to do with persistence, you can still have non-
volatile data be in an "in-memory" DB and take snapshots of it, but even so,
what about when you decide you need to scale your compute but not your RAM and
move the data structure to a networked box, or when you need to have more than
one local process read the same data structure, or when you want to ensure
your architecture will always support such a thing _if_ you need to, or if
your language doesn't have a decent implementation of a particular data
structure, or etc.

~~~
easytiger
It might make it convenient to do those things, but it doesn't make it a
database really though does it? The article admits it doesn't have to handle
the most complex problems associated with data persistence (getting
transactional blocks of data to a storage medium).

Your examples become a problem if your graph can't fit in the RAM of one host.
If not that, then you have then distinct graphs to handle, and so a
paralellisable problem to be handled by multiple processes. All you have in
that case is an abstraction which lets you have a unified interface to all of
them. Notably that also isn't relevant as the one in the article doesn't do
any of that. It is a graph library.

