È stato rilasciato rqlite 6.0, un database distribuito che utilizza SQLite come motore di archiviazione e consente di organizzare un cluster di archiviazione sincronizzati tra loro. Tra le caratteristiche di rqlite spiccano la facilità d'installazione, distribuzione e manutenzione di un'archiviazione distribuita e resiliente, simile a etcd e Consul, ma che utilizza un modello relazionale per la gestione dei dati invece del formato chiave/valore. Il codice del progetto è scritto in Go e distribuito con licenza MIT.
Per mantenere tutti i nodi in uno stato sincronizzato, viene utilizzato l'algoritmo di consenso Raft. Rqlite utilizza la libreria originale SQLite e il driver go-sqlite3 standard, su cui viene eseguita un'interfaccia che gestisce le richieste dei clienti, esegue la replica su altri nodi e monitora il conseguimento del consenso per la selezione del nodo leader.
Le modifiche nel database possono essere apportate solo dal nodo designato come leader, ma le connessioni con le operazioni di scrittura possono essere indirizzate anche ad altri nodi del cluster, i quali restituiranno l'indirizzo del leader per ripetere la richiesta (nella prossima versione si promette di aggiungere l'inoltro automatico della richiesta al leader). L'accento è posto sulla resilienza, quindi il database può scalare solo per le operazioni di lettura, mentre le operazioni di scrittura rappresentano un collo di bottiglia. È possibile avviare un cluster rqlite da un solo nodo e questa soluzione può essere utilizzata per fornire accesso a SQLite tramite HTTP senza offrire resilienza.
I dati di SQLite su ogni nodo non sono memorizzati in un file, ma in memoria. A livello del layer con l'implementazione del protocollo Raft viene mantenuto un log di tutti i comandi SQLite che provocano modifiche al database. Questo log viene utilizzato durante la replica (replica a livello di riproduzione delle richieste su altri nodi), per l'avvio di un nuovo nodo o per il recupero dopo una perdita di connessione. Per ridurre la dimensione del log viene utilizzata una compressione automatica, che viene attivata dopo un numero prestabilito di modifiche e porta alla registrazione su disco di uno snapshot, rispetto al quale inizia un nuovo log (lo stato del database in memoria è identico allo snapshot + il log delle modifiche accumulate).
Caratteristiche di rqlite:
- Semplicità nel dispiegamento di un cluster, senza necessità di installare SQLite separatamente.
- Possibilità di ottenere rapidamente uno storage SQL replicato.
- Pronto per l'uso in progetti lavorativi (Production-grade).
- Disponibilità di un'API HTTP(S) che consente di aggiornare i dati in modalità batch e di determinare il nodo leader del cluster. Viene fornita anche un'interfaccia a riga di comando e la possibilità di utilizzare varie librerie client create per SQLite.
- Disponibilità di un servizio per l'individuazione di altri nodi, che consente di creare cluster dinamicamente.
- Supporto per la crittografia della comunicazione dei dati tra i nodi.
- Possibilità di configurare il livello di verifica della validità e coerenza dei dati durante la lettura.
- Opzione per collegare nodi in modalità di sola lettura, che non partecipano alla definizione del consenso e sono utilizzati per aumentare la scalabilità del cluster per le operazioni di lettura.
- Supporto per una forma personalizzata di transazioni basata sulla combinazione di comandi in un'unica richiesta (non sono supportate transazioni basate su BEGIN, COMMIT, ROLLBACK, SAVEPOINT e RELEASE).
- Supporto per la creazione di backup a caldo.
Il nuovo rilascio presenta significativi cambiamenti architettonici finalizzati a migliorare l'affidabilità del cluster tramite il miglioramento del processo di instradamento delle richieste di lettura e scrittura ai nodi corretti del cluster. I nodi rqlite ora possono multiplexare tra loro più connessioni logiche utilizzando connessioni TCP stabilite tra i nodi tramite il protocollo Raft. Se una richiesta richiede le autorizzazioni del nodo leader, ma viene inviata a un nodo secondario, il nodo secondario può determinare l'indirizzo del leader e comunicarlo al cliente, senza eseguire il calcolo del consenso secondo il protocollo Raft.
La modifica ha anche eliminato la necessità di un componente separato per la sincronizzazione dei metadati e ha escluso la gestione separata dello stato Raft e dei metadati. I nodi secondari ora indirizzano le richieste al nodo leader solo quando necessario, per ottenere l'indirizzo del nodo leader. Nell'API è stata inclusa la possibilità di ottenere informazioni sullo stato degli altri nodi nel cluster. È stato aggiunto il comando «.sysdump» nell'interfaccia a riga di comando.
Fonte: opennet.ru
