Gli sviluppatori di SQLite stanno sviluppando un modulo VFS sperimentale CBS (Cloud Backed SQLite), che consente di archiviare il contenuto del database non in un file locale, ma in un archivio cloud esterno. Per l'archiviazione viene utilizzato un formato di database appositamente ottimizzato per l'archiviazione esterna, che consente di caricare i dati dall'archivio esterno in modo dinamico secondo necessità, senza dover copiare preventivamente l'intero database sul sistema locale. Attualmente sono supportati gli archivi cloud Azure Blob Storage e Google Cloud Storage. Qualsiasi applicazione in grado di lavorare con il normale SQLite può essere migrata per utilizzare CBS.
Il modulo VFS può operare in modalità di sfondo e attiva. In modalità di sfondo, un processo di sfondo è sempre in esecuzione nel sistema, permettendo di accedere al database esterno solo in modalità di sola lettura, ma supportando una cache condivisa a cui possono accedere diversi processi. In modalità attiva, sono consentite lettura e scrittura, ma viene utilizzata solo la cache locale del processo corrente. In un dato momento, solo un cliente può eseguire scritture, e gli altri clienti non vedranno le modifiche scritte finché non le richiederanno esplicitamente dall'archivio cloud. Per separare le diverse richieste di scrittura viene applicato un sistema di blocco tipico di SQLite basato sul WAL-log.
Agli sviluppatori viene fornito un'estesa API C e un'interfaccia da linea di comando, che consentono di eseguire operazioni come la creazione e la pulizia dell'archivio esterno, il caricamento e il download di database nell'archivio esterno, la creazione di una copia del database nell'archivio esterno, la visualizzazione dell'elenco dei database nell'archivio cloud e la rimozione dei blocchi non utilizzati dall'archivio cloud.
I programmatori del progetto libSQL (un fork avanzato di SQLite) hanno annunciato una versione server di SQLite — sqld, che consente la gestione di un database relazionale condiviso. I client possono connettersi utilizzando il protocollo PostgreSQL o HTTP. Ad esempio, per connettersi a sqld possono essere utilizzate le librerie client esistenti create per il database PostgreSQL, così come l'interfaccia a riga di comando psql. È possibile accedere al server sqld anche tramite API basate su HTTP, semplificando l'integrazione con le applicazioni web. Il codice di sqld è scritto in Rust ed è distribuito con licenza MIT.
Tra le aree di applicazione di sqld si segnalano il backup, la replica su altri sistemi e l'organizzazione dell'accesso al database SQLite in infrastrutture serverless, dove non è presente uno storage permanente e non è possibile mantenere il database in un file locale. Nei sistemi serverless, il database con cui lavora sqld può essere replicato da altri. server. Per garantire un'alta disponibilità e tolleranza ai guasti, è supportata l'integrazione con mvSQLite (una versione distribuita di SQLite che funziona su FoundationDB). È disponibile una modalità di mantenimento di una copia di backup attiva, realizzata tramite il salvataggio periodico di snapshot dello stato del database e la replicazione delle modifiche dal WAL-log a uno storage cloud compatibile con Amazon S3.
Per le applicazioni è disponibile una libreria compatibile con SQLite, che può essere caricata tramite LD_PRELOAD per passare dallo storage locale dei dati a lavorare tramite sqld. È possibile caricare estensioni per SQLite. Le librerie client sono pronte per TypeScript, JavaScript, Rust, Go e Python. È possibile lavorare con un database associato a sqld utilizzando gli strumenti standard di SQLite, quindi sqld funge da layer per fornire accesso di rete al database, replica e backup. Ad esempio: # Avviamo il server per il database SQLite foo.db: sqld -d foo.db -p 127.0.0.1:5432 —http-listen-addr=127.0.0.1:8000 # Accediamo al database utilizzando gli strumenti di PostgreSQL: psql -q postgres://127.0.0.1 # Ci connettiamo localmente al database utilizzando gli strumenti di SQLite: sqlite3 foo.db # Accediamo tramite HTTP: curl -s -d «{"statements": ["SELECT * from databases;"] }» \ http://127.0.0.1:8000
In conclusione, vale la pena menzionare il progetto LiteFS, sviluppato dall'azienda Fly.io. LiteFS è un modulo FUSE per gestire un database SQLite condiviso su più host. LiteFS replica lo stato del database tra più sistemi intercettando le operazioni di scrittura nel file del database e trasmettendo queste operazioni ad altri sistemi, utilizzando un meccanismo simile alle transazioni e salvando le transazioni in un file separato nel formato LTX. Il codice di LiteFS è scritto in Go e distribuito sotto licenza Apache 2.0.
Fonte: opennet.ru
