[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