cobalt
Uno store key-value embedded di tipo LSM in Zig. Le scritture recenti finiscono in una skiplist su WAL, vengono scaricate in SSTable immutabili e lo spazio viene recuperato dalla leveled compaction.
Un archivio chiave-valore LSM incorporato in Zig. Le scritture fresche atterrano in una skiplist basata su WAL, poi vengono scaricate in SSTable immutabili, e il leveled compaction recupera lo spazio. È il fondamento su cui poggiano i database moderni.
Introduzione
I database moderni che usi ogni giorno hanno quasi sempre la stessa forma di motore sotto. cobalt esiste perché quella forma smetta di essere una scatola nera: implementa l'intero percorso di scrittura LSM dal log alla compaction, in Zig, un linguaggio che non ti nasconde un solo byte né un'allocazione.
Non è l'ennesimo database per la produzione ma un motore smontato nei suoi pezzi in cui ogni decisione è visibile. Una volta che scrivi tu stesso WAL, memtable, SSTable e compaction, RocksDB e Cassandra smettono di essere magia e diventano varianti familiari della stessa idea.
Perché LSM e non un B-albero
I database classici scrivono sul posto, aggiornando pagine di B-albero, il che significa scritture casuali sul disco. LSM va nella direzione opposta: ogni scrittura è un'aggiunta. I nuovi dati atterrano in una struttura in memoria mentre gli strati più vecchi giacciono immutabili sul disco. Questo rende le scritture veloci e sequenziali, perché le scritture sequenziali sono esattamente ciò che un disco preferisce.
Il costo è chiaro e deliberato: gli stessi dati possono vivere in più posti contemporaneamente e devono essere fusi in seguito. Tutta l'arte dell'LSM consiste nel pagare quel debito in background senza rallentare le scritture che lo creano.
Il percorso di scrittura, passo dopo passo
una scrittura colpisce prima il log, quindi sopravvive a uno spegnimento improvviso prima di atterrare altrove.
i dati freschi stanno in una struttura in memoria ordinata, pronti per letture veloci.
quando la memoria si riempie, la skiplist viene scaricata in un file immutabile e ordinato sul disco.
il leveled compaction fonde i file tra i livelli, scarta le versioni sovrascritte e recupera lo spazio.
L'ordine di questi passi non è casuale. Il WAL viene per primo proprio perché garantisce la durabilità prima che i dati raggiungano la memoria volatile. Se l'ordine fosse invertito, un'interruzione di corrente tra la scrittura in memoria e il log significherebbe una perdita silenziosa di dati.
La compaction è il cuore che distingue un LSM funzionante da uno che con il tempo si strozza. Senza di essa i file SSTable si accumulano all'infinito e una lettura deve esaminare sempre più strati. Il leveled compaction li fonde tra i livelli, buttando via lungo il cammino le versioni sovrascritte e recuperando lo spazio occupato dai dati morti.
La stessa forma di motore, WAL più memtable più SSTable più compaction, è ciò che trovi in RocksDB, LevelDB e Cassandra. La differenza tra loro è per lo più la messa a punto degli stessi mattoni, non un'architettura diversa.
La fine della scatola nera
Il guadagno più grande di cobalt non è l'archivio stesso ma che i grandi database smettono di essere un mistero. Una volta percorso tutto il cammino dall'aggiunta al log al recupero dello spazio nella compaction, sai esattamente perché LSM è veloce in scrittura e dove lo paga in lettura.
Gli strati del motore e dove vivono anche
| Strato | Ruolo | Dove altro |
|---|---|---|
| WAL | durabilità della scrittura | ogni database serio |
| Memtable (skiplist) | dati freschi in memoria | RocksDB, LevelDB |
| SSTable | file immutabili sul disco | Cassandra, LevelDB |
| Compaction | recupero spazio, fusione | RocksDB, Cassandra |
Altri progetti
Altri lavori della stessa categoria - scopri come affrontiamo sfide simili.
Hai un progetto simile?
Contattaci - il preventivo è gratuito e arriva entro un'ora.