<div dir="ltr">This is kind of refreshing. I like the simplicity of the goal. I did a similar thing , not a database but something that can be distributed by linking nodes. Atomicity is done inside a batch and you have CAS features as well. Storage can be persisted or in memory. Default backend is roclksdb or rocksdb in temporary db in RAM.<div><br></div><div>the core : <a href="https://gitlab.com/benoitc/openkvs">https://gitlab.com/benoitc/openkvs</a></div><div>doc: <a href="https://gitlab.com/benoitc/openkvs-doc">https://gitlab.com/benoitc/openkvs-doc</a></div><div><br></div><div>and you have an HTTP frontend also that was started:  <a href="https://gitlab.com/benoitc/openkvs-http">https://gitlab.com/benoitc/openkvs-http</a></div><div><br></div><div>I am revisiting all of these projects these days , time is limited sometimes :) Maybe we can find common goal.</div><div><br></div><div>Benoît</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 21, 2021 at 2:57 PM Roberto Ostinelli <<a href="mailto:ostinelli@gmail.com">ostinelli@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Let’s write a database! Well not really, but I think it’s a little sad that there doesn’t seem to be a simple in-memory distributed KV database in Erlang. Many times all I need is a consistent distributed ETS table.<br><br>The two main ones I normally consider are:<br><br><ul><li><b>Riak</b> which is great, it handles loads of data and is based on DHTs. This means that when there are cluster changes there is a need for redistribution of data and the process needs to be properly managed, with handoffs and so on. It is really great but it’s eventually consistent and on many occasions it may be overkill when all I’m looking for is a simple in-memory ACI(not D) KV solution which can have 100% of its data replicated on every node.</li><li><b>mnesia</b> which could be it, but unfortunately requires special attention when initializing tables and making them distributed (which is tricky), handles net splits very badly, needs hacks to resolve conflicts, and does not really support dynamic clusters (additions can be kind of ok, but for instance you can’t remove nodes unless you stop the app).</li><li>…other solutions? In general people end up using Foundation DB or REDIS (which has master-slave replication), so external from the beam. Pity, no?</li></ul><br>So… :) Well I don’t plan to write a database (since ETS is <i>awesome</i>), rather distributing it in a cluster. I’d simply want a distributed ETS solution after all!<br><br>I’ve already started the work and released a version 0.1.0 or ram:<br><a href="https://github.com/ostinelli/ram" target="_blank">https://github.com/ostinelli/ram</a><br><br>Docs are here:<br><a href="https://hexdocs.pm/ram" target="_blank">https://hexdocs.pm/ram</a><br><br>Please note this is a very early stage. It started as an experiment and it might remain one. So feedback is welcome to decide its future!<br><div><br></div><div>Best,</div><div>r.</div></div>
</blockquote></div>