Distributed Key-Value DB

I database non relazionali sono distinti per la loro scalabilità orizzontale e fault tolerance. Nell'ottica del teorema CAP significa che si vuole sacrificare la consistenza rigida a favore di availability, partitioning tolerance e velocità di elaborazione delle richieste.

A tal fine, molte architetture dei database non relazionali godono della distribuzione delle repliche di dati su più unità di elaborazione paritarie connesse da una rete logica. In questo modo un fault o partitioning di un nodo non compromette l'integrità e la funzionalità del sistema intero, che dal punto di vista di client rimane sempre un'entità unica con la distribuzione trasparente. Tuttavia questa potenziale inconsistenza temporanea crea una serie di complicazioni da affrontare, tra cui la più importante è l'eventual consistency.

Uno dei possibili approci per ottenere la consistenza nei sistemi multi-agente è l'utilizzo dei protocolli di consenso. Un'idea possibile per il raggiungimento del consenso è coordinare i valori tramite un voto di consenso della maggioranza degli agenti. Tuttavia, uno o più processi difettosi possono distorcere il risultato e il consenso potrà non essere raggiunto, o essere raggiunto errato. Per questo motivo i protocolli che risolvono i problemi di consenso sono progettati per gestire un numero limitato di processi difettosi, per esempio la famiglia dei protocolli Paxos.

Questo progetto si pone come obiettivo di implementare un database non relazionale di tipo key-value distribuito su un cluster di nodi nei quali vengono replicati i dati in modo da offire availability nel caso di fault o network partitioning di singoli nodi. La struttura distribuita deve rimanere trasparente al client, al quale deve essere esposta un'interfaccia REST per le operazioni CRUD. L'inserimento dei nodi nuovi deve essere sufficientemente semplice e rapido. Per garantire l'eventual consistency viene proposto l'utilizzo di protocollo di consenso Raft, una variante semplificata del protocollo Paxos.