Vi är stora fans av att använda SQLite för allt av måttlig komplexitet där du annars skulle kunna använda en fil. Fördelarna är många, men ibland vill man vara mager med fillagring. [Phiresky] har ett bra svar på det: tillägget sqlite-zstd erbjuder transparent komprimering på radnivå för SQLite.

Det finns naturligtvis andra alternativ, men som inlägget nämner har var och en av dessa några nackdelar. Men genom att komprimera varje rad i en tabell kan du behålla slumpmässig åtkomst utan några av nackdelarna med andra metoder.

Ett komprimerat bord har en okomprimerad vy och ett underliggande komprimerat bord. Kompressionsordlistan laddas för varje tabell och cachelagras för att förbättra prestandan. Ur applikationens synvinkel är den okomprimerade vyn bara en normal tabell och du borde inte behöva några kodändringar.

Du kan välja hur komprimeringen grupperar data som kan hjälpa till med prestanda. Till exempel, istället för att sätta ihop ett fast antal rader, kan du komprimera grupper av poster baserat på datum eller till och med bara fixa en enda ordbok som kan vara användbar för tabeller som aldrig ändras.

På tal om prestanda så sker dekompression i farten, men komprimering och ordboksbyggande görs i bakgrunden när databasen annars är inaktiv. Benchmarks visar viss prestandaträff, så klart, men så är det alltid: du byter hastighet mot utrymme. Å andra sidan, för slumpmässig åtkomst är det faktiskt snabbare att använda komprimerade tabeller eftersom det finns mindre data att läsa. Slumpmässiga uppdateringar var dock långsammare även om komprimering inte inträffar vid den tiden.

Om du vill ha en snabb start med SQLite finns det en Linux Fu för det. Du kan till och med använda versionering med ett Git-liknande system, en annan fördel jämfört med traditionella filer.