Re: [ANN] ram, an in-memory distributed KV store
Benoit Chesneau <[email protected]> Wed, 22 Dec 2021 14:46:54 +0100
| Newsgroups | gmane.comp.lang.erlang.general |
|---|---|
| Message-ID | <CAJNb-9oUXZJNK0kGqi_vSNYfvsh8BNMmubEUM9La5s4uZQSVEQ@mail.gmail.com> |
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 <[email protected]> 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. >