4 ms·
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 i
by JulianWasTaken 8y ago
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 8y agoIt 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.