Re: [ANN] ram, an in-memory distributed KV store
Benoit Chesneau <[email protected]> Wed, 22 Dec 2021 14:23:01 +0100
| Newsgroups | gmane.comp.lang.erlang.general |
|---|---|
| Message-ID | <CAJNb-9oHCcx4x-91mE8=nK3v9j_=3x7zL6zYwdwEwWTWZLUJew@mail.gmail.com> |
while we are here let's add cached to the comparison: https://gitlab.com/barrel-db/lab/cached 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: https://gitlab.com/barrel-db/lab/cached/-/blob/master/test/cached_SUITE.erl#L47 Benoît On Wed, Dec 22, 2021 at 1:51 PM Attila Rajmund Nohl <[email protected]> wrote: > Roberto Ostinelli <[email protected]> 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... >