All Projects → gryadka → Js

gryadka / Js

Licence: mit
Gryadka is a minimalistic master-master replicated consistent key-value storage based on the CASPaxos protocol

Programming Languages

javascript
184084 projects - #8 most used programming language

Projects that are alternatives of or similar to Js

Etcd
Distributed reliable key-value store for the most critical data of a distributed system
Stars: ✭ 38,238 (+12478.29%)
Mutual labels:  key-value, consensus, distributed-database, distributed-systems
Zookeeper
Apache ZooKeeper
Stars: ✭ 10,061 (+3209.54%)
Mutual labels:  distributed-systems, key-value, consensus, distributed-database
Verdi Raft
An implementation of the Raft distributed consensus protocol, verified in Coq using the Verdi framework
Stars: ✭ 143 (-52.96%)
Mutual labels:  key-value, consensus, distributed-systems
Elasticell
Elastic Key-Value Storage With Strong Consistency and Reliability
Stars: ✭ 453 (+49.01%)
Mutual labels:  key-value, distributed-database, distributed-systems
Raft
Raft Consensus Algorithm
Stars: ✭ 370 (+21.71%)
Mutual labels:  consensus, distributed-database, distributed-systems
Rqlite
The lightweight, distributed relational database built on SQLite
Stars: ✭ 9,147 (+2908.88%)
Mutual labels:  consensus, distributed-database, distributed-systems
Hraftd
A reference use of Hashicorp's Raft implementation
Stars: ✭ 732 (+140.79%)
Mutual labels:  key-value, consensus, distributed-systems
Olric
Distributed cache and in-memory key/value data store. It can be used both as an embedded Go library and as a language-independent service.
Stars: ✭ 2,067 (+579.93%)
Mutual labels:  key-value, distributed-database
Justindb
⚛️ JustinDB is a highly available globally distributed key-value data store.
Stars: ✭ 147 (-51.64%)
Mutual labels:  key-value, distributed-database
raft-badger
Badger-based backend for Hashicorp's raft package
Stars: ✭ 27 (-91.12%)
Mutual labels:  key-value, consensus
little-raft
The lightest distributed consensus library. Run your own replicated state machine! ❤️
Stars: ✭ 316 (+3.95%)
Mutual labels:  distributed-systems, consensus
Arangodb
🥑 ArangoDB is a native multi-model database with flexible data models for documents, graphs, and key-values. Build high performance applications using a convenient SQL-like query language or JavaScript extensions.
Stars: ✭ 11,880 (+3807.89%)
Mutual labels:  key-value, distributed-database
Zanredisdb
Yet another distributed kvstore support redis data and index. moved to: https://github.com/youzan/ZanRedisDB
Stars: ✭ 64 (-78.95%)
Mutual labels:  key-value, distributed-database
docs
Source code of the ArangoDB online documentation
Stars: ✭ 18 (-94.08%)
Mutual labels:  key-value, distributed-database
huffleraft
Replicated key-value store driven by the raft consensus protocol 🚵
Stars: ✭ 32 (-89.47%)
Mutual labels:  distributed-systems, key-value
Tikv
Distributed transactional key-value database, originally created to complement TiDB
Stars: ✭ 10,403 (+3322.04%)
Mutual labels:  key-value, consensus
raftor
Distributed chat system built with rust
Stars: ✭ 31 (-89.8%)
Mutual labels:  distributed-systems, consensus
Trino
Official repository of Trino, the distributed SQL query engine for big data, formerly known as PrestoSQL (https://trino.io)
Stars: ✭ 4,581 (+1406.91%)
Mutual labels:  distributed-database, distributed-systems
coolbeans
Coolbeans is a distributed work queue that implements the beanstalkd protocol.
Stars: ✭ 56 (-81.58%)
Mutual labels:  distributed-systems, consensus
apollo
An experimental distributed ledger platform based on a sea of DAG Nodes
Stars: ✭ 33 (-89.14%)
Mutual labels:  consensus, distributed-database

Gryadka is a minimalistic master-master replicated consistent key-value storage based on the CASPaxos protocol. It uses Redis as a backend and makes multiple Redis instances work as a whole tolerating up to F failures out of 2F+1 nodes.

Its core has less than 500 lines of code but provides full-featured Paxos implementation supporting such advanced features as cluster membership change (ability to add/remove nodes to a cluster) and distinguished proposer optimization (using one round trip to change a value instead of two).

Is it correct?

Yes, the protocol has formal proof (see the CASPaxos paper) and TLA+ models independently written by Greg Rogers and Tobias Schottdorf:

Moreover, the implementation was heavily tested with fault injections on the network layer.

Is it production ready?

No, it's an educational project, and it was never intended to be deployed in production. The goal of the project is to build master-master replicated consistent key-value storage as simple as possible.

Even though Gryadka is an educational project, its operational characteristics surpass established databases (see the comparison).

API

Gryadka's core interface is a change function which takes two arguments:

  • a key
  • a update function

change gets a value associated with the key, applies update to calculate a new value, saves and returns it.

The pseudo-code:

class Paxos {
  constuctor() {
    this.storage = ...;
  }
  change(key, update) {
    const value = update(this.storage.get(key));
    this.storage.set(key, value);
    return value;
  }
}

By choosing the appropriate update functions, it's possible to customize Gryadka to fulfill different tasks. A "last write win" key/value could be implemented as:

class LWWKeyValue {
  constuctor(paxos) {
    this.paxos = paxos;
  }
  read(key) {
    return this.paxos.change(key, x => x);
  }
  write(key, value) {
    return this.paxos.change(key, x => value);
  }
}

A key/value storage with compare-and-set support may look like:

class CASKeyValue {
  constuctor(paxos) {
    this.paxos = paxos;
  }
  read(key) {
    return this.paxos.change(key, x => x==null ? { ver: 0, val: null} : x);
  }
  write(key, ver, val) {
    return this.paxos.change(key, x => {
      if (x.ver != ver) throw new Error();
      return { ver: ver+1, val: val };
    });
  }
}

Dockerized example of cluster membership change

Please see https://github.com/gryadka/js/tree/master/http-example for an example of:

  • Dockerized Gryadka-based cluster
  • Using Gryadka to build a HTTP key-value storage
  • Cluster membership change

Additional information about cluster membership change is in the CASPaxos paper and in the simulation tests (see 2p2k2.a3.a4 and c2p2k2.flux tests):

Tests

Testing is done by mocking the network layer and checking consistency invariants during various network fault injections such as message dropping and message reordering.

See https://github.com/gryadka/js/tree/master/simulation for more information.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].