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

Benoit Chesneau bchesneau@REDACTED
Wed Dec 22 14:23:01 CET 2021

while we are here let's add cached to the comparison:

Only the experiment is public for now. It has different strategies to store
k/v in memory and distribute it. Distribution is plugable and by default
rely on erlang distribution.

Quick sample:


On Wed, Dec 22, 2021 at 1:51 PM Attila Rajmund Nohl <attila.r.nohl@REDACTED>

> Roberto Ostinelli <ostinelli@REDACTED> ezt írta (időpont: 2021. dec.
> 21., K, 14:57):
> >
> > 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?
> Have you seen this: https://gitlab.com/leapsight/plum_db ? It's only
> eventually consistent, but if you want distribution and availability
> even in case of network partitioning, you won't get consistency...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20211222/0a90b5eb/attachment.htm>

More information about the erlang-questions mailing list