[ANN] ram, an in-memory distributed KV store

Benoit Chesneau bchesneau@REDACTED
Wed Dec 22 14:46:54 CET 2021


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.

the core : https://gitlab.com/benoitc/openkvs
doc: https://gitlab.com/benoitc/openkvs-doc

and you have an HTTP frontend also that was started:
https://gitlab.com/benoitc/openkvs-http

I am revisiting all of these projects these days , time is limited
sometimes :) Maybe we can find common goal.

Benoît

On Tue, Dec 21, 2021 at 2:57 PM Roberto Ostinelli <ostinelli@REDACTED>
wrote:

> 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.
>
> The two main ones I normally consider are:
>
>
>    - *Riak* 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.
>    - *mnesia* 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).
>    - …other solutions? In general people end up using Foundation DB or
>    REDIS (which has master-slave replication), so external from the beam.
>    Pity, no?
>
>
> So… :) Well I don’t plan to write a database (since ETS is *awesome*),
> rather distributing it in a cluster. I’d simply want a distributed ETS
> solution after all!
>
> I’ve already started the work and released a version 0.1.0 or ram:
> https://github.com/ostinelli/ram
>
> Docs are here:
> https://hexdocs.pm/ram
>
> 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!
>
> Best,
> r.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20211222/f524d907/attachment.htm>


More information about the erlang-questions mailing list