DoltLite (versie 0.50.0) is nu in Beta. Het project is een fork van SQLite waarbij de B-tree laag is vervangen door een Prolly Tree, waardoor de database Git-achtige functionaliteiten krijgt.
De belangrijkste aspecten van de Beta-versie zijn:
- Volledig versiebeheer: Gebruikers kunnen databases branchen, mergen, diffen en synchroniseren via push, pull, clone en fetch, met ondersteuning voor DoltHub.
- SQL-compatibiliteit: DoltLite is zeer compatibel met SQLite en doorstaat het overgrote deel van de standaard SQLite-testsuites.
- Stabiliteit: Het opslagformaat is nu stabiel, waardoor gebruikers de software kunnen adopteren zonder angst voor brekende wijzigingen in de data.
- Prestaties: Hoewel de leessnelheid bijna gelijk is aan die van SQLite, zijn schrijfacties trager vanwege het versiebeheer. De auteur adviseert het gebruik van gebundelde (batched) schrijfacties om de prestaties te optimaliseren.
DoltLite Beta
Mijn baby wordt volwassen. Slechts vijf maanden na de lancering is DoltLite in Beta, versie 0.50.0.
DoltLite begon als een experiment. Ik had een zijproject nodig om de innovatieve agent-orchestrator van Steve Yegge, Gas Town, te testen. Ik wilde een echt probleem oplossen, geen speelgoedproject. We wilden al jaren een embedded versie van Dolt, maar het herschrijven van de storage engine van Dolt in C of Rust was een brug te ver. SQLite leek een logische gastheer voor die engine. Zou een team van agents het kunnen redden? Het kostte ongeveer 2.000 pull requests, maar het feit dat DoltLite nu in Beta is, bewijst dat een team van agents dit zeker kan.
Dit artikel legt uit wat DoltLite is en wat een Beta-lancering precies betekent.
Wat is DoltLite?
DoltLite is een fork van SQLite. Alles boven de B-tree laag is identiek. Dat betekent dat de SQL-parser en -analyzer, de interactielaag met het bestandssysteem en de testomgeving standaard SQLite zijn. Bij andere Dolt-producten moesten we een SQL-engine implementeren bovenop versiebeheerde opslag. Het bouwen van een SQL-engine is moeilijk. Met DoltLite kregen we er een, tegen de kosten van het schrijven van een versiebeheerde storage engine in C.
De B-tree laag is vervangen door een Prolly Tree, ondersteund door een single file chunk store. Prolly Trees zijn content-addressed B-trees. Deze magische datastructuur drijft de versiebeheerfunctionaliteit aan in alle Dolt-producten.
Dit betekent dat je alle versiebeheerfuncties van Dolt en Git krijgt in een SQLite-pakket. Heb je ooit gewild dat je SQLite kon branchen, mergen en diffen? Dan is DoltLite voor jou. Of, misschien nog belangrijker: heb je ooit gewild dat je een conflict-bewuste SQLite-sync engine had, aangedreven door Git-stijl push, pull, clone en fetch? Dan is DoltLite voor jou. Je kunt zelfs DoltHub gebruiken als je sync-backend.
Wat betekent Beta?
Wat betekent het feit dat DoltLite in Beta gaat nu concreet voor jou? Beta betekent vier dingen:
- Stabiliteit van het opslagformaat
- SQL-compatibiliteit
- Volledig versiebeheer
- Productieprestaties
De rapporten vanuit het veld over functionaliteit en stabiliteit zijn universeel positief. De testbatterij van SQLite is werkelijk indrukwekkend. DoltLite doorstaat deze tests, evenals een aangepaste suite van Dolt-oracle-tests. DoltLite is klaar om door jou geprobeerd te worden.
Stabiliteit van het opslagformaat
De grootste klacht over het ontwikkelingsproces van DoltLite waren de wijzigingen in het opslagformaat. Wijzigingen in het formaat waren niet achterwaarts compatibel, waardoor gebruikers op dezelfde versie moesten blijven of hun databases handmatig moesten dumpen en opnieuw importeren. Er waren 12 formaatwijzigingen nodig om bij de Beta-versie te komen. We gebruiken het huidige formaat nu al 57 releases, of meer dan drie kalendermaanden. Dit formaat lijkt een formaat waar we bij kunnen blijven.
Het opslagformaat is nu stabiel. Eventuele toekomstige ingrijpende wijzigingen zullen een ondersteund migratiepad hebben. DoltLite Beta betekent dat je het kunt adopteren zonder angst voor een brekende wijziging in het opslagformaat.
SQL-compatibiliteit
De SQL-laag van SQLite is extreem goed getest. DoltLite doorstaat het overgrote deel van deze tests eveneens, wat de SQL-compatibiliteit bewijst.
DoltLite doorstaat 100% van sqllogictest, een suite van 5,8 miljoen complexe queries. De query-laag is identiek aan die van SQLite, dus dit is verwacht.
SQLite wordt ook geleverd met een suite van 892.277 TCL-gebaseerde acceptatietests die een breder oppervlak van de SQLite-API testen. DoltLite doorstaat hiervan 99,46%, met 4.809 bekende divergenties. Voor elke divergentie moet een reden zijn vermeld. De belangrijkste redenen zijn:
- Tabellen zijn gekoppeld aan een primary key in plaats van een
rowid, om versiebeheerfunctionaliteit te ondersteunen. Sommige tests inspecteren direct de rowid.
- DoltLite maakt gebruik van chunks in plaats van pages. Sommige tests inspecteren direct de pages.
- Er is geen WAL- of journal-sidecar. WAL- en journal-tests worden overgeslagen.
SQLite-gebruikers zullen zich thuis voelen bij DoltLite. DoltLite werkt als SQLite, maar met extra versiebeheerfuncties.
Volledig versiebeheer
DoltLite implementeert de kernsuite van de Git-stijl versiebeheerfuncties van Dolt.
Lokale versiebeheerfuncties worden ondersteund, waaronder: branches, merges, diffs, rebases, cherry-picks en resets. Remote versiebeheer wordt eveneens ondersteund: push, pull, clone en fetch vanuit een aangepaste remote of DoltHub.
Je hebt zelfs de volledige Dolt Workbench GUI tot je beschikking, inclusief de agent-modus. Laat een agent los op je SQLite en gebruik dolt_reset('--hard') als hij iets verpest.
Productieprestaties
DoltLite biedt embedded database-prestaties op microseconde-schaal, maar met een "belasting" op de schrijfsnelheid vanwege het versiebeheer. De leessnelheid is bijna gelijkwaardig.
Elke nacht wordt er op GitHub een prestatierapport gepubliceerd waarin DoltLite wordt vergeleken met SQLite op basis van een standaard sysbench-stijl benchmark. Het rapport van gisteravond laat zien dat in-memory DoltLite-databases 10% langzamer zijn bij lezen en 60% langzamer bij schrijven. Databases op basis van bestanden zijn gelijkwaardig bij lezen en 10% langzamer bij gebundelde (batched) schrijfacties.
De grote uitschieter zijn kleine autocommit writes, die 3,1 keer langzamer zijn dan bij SQLite. Prestatiegevoelige DoltLite-workflows zouden zoveel mogelijk gebruik moeten maken van gebundelde schrijfacties. Zelfs voor autocommit-writes praten we over individuele schrijfprestaties in microseconden (dus onder de milliseconde): ongeveer 125 microseconden in SQLite tegenover ongeveer 400 microseconden in DoltLite op een kleine GitHub-runner.
Conclusie
DoltLite is in Beta! Het enige waar we nu nog op wachten, zijn gebruikers. Probeer DoltLite vandaag nog uit voor jouw embedded Dolt-gebruiksscenario's. Als je hulp nodig hebt, kun je terecht op ons Discord-kanaal in de #doltlite<0xF0><0x9F><0xAA><0xB6> channel.
DoltLite Beta
Mijn baby wordt volwassen. Slechts vijf maanden na de lancering is DoltLite in Beta, versie 0.50.0.
DoltLite begon als een experiment. Ik had een zijproject nodig om de innovatieve agent-orchestrator van Steve Yegge, Gas Town, te testen. Ik wilde een echt probleem oplossen, geen speelgoedproject. We wilden al jaren een embedded versie van Dolt, maar het herschrijven van de storage engine van Dolt in C of Rust was een brug te ver. SQLite leek een logische gastheer voor die engine. Zou een team van agents het kunnen redden? Het kostte ongeveer 2.000 pull requests, maar het feit dat DoltLite nu in Beta is, bewijst dat een team van agents dit zeker kan.
Dit artikel legt uit wat DoltLite is en wat een Beta-lancering precies betekent.
Wat is DoltLite?
DoltLite is een fork van SQLite. Alles boven de B-tree laag is identiek. Dat betekent dat de SQL-parser en -analyzer, de interactielaag met het bestandssysteem en de testomgeving standaard SQLite zijn. Bij andere Dolt-producten moesten we een SQL-engine implementeren bovenop versiebeheerde opslag. Het bouwen van een SQL-engine is moeilijk. Met DoltLite kregen we er een, tegen de kosten van het schrijven van een versiebeheerde storage engine in C.
De B-tree laag is vervangen door een Prolly Tree, ondersteund door een single file chunk store. Prolly Trees zijn content-addressed B-trees. Deze magische datastructuur drijft de versiebeheerfunctionaliteit aan in alle Dolt-producten.
Dit betekent dat je alle versiebeheerfuncties van Dolt en Git krijgt in een SQLite-pakket. Heb je ooit gewild dat je SQLite kon branchen, mergen en diffen? Dan is DoltLite voor jou. Of, misschien nog belangrijker: heb je ooit gewild dat je een conflict-bewuste SQLite-sync engine had, aangedreven door Git-stijl push, pull, clone en fetch? Dan is DoltLite voor jou. Je kunt zelfs DoltHub gebruiken als je sync-backend.
Wat betekent Beta?
Wat betekent het feit dat DoltLite in Beta gaat nu concreet voor jou? Beta betekent vier dingen:
- Stabiliteit van het opslagformaat
- SQL-compatibiliteit
- Volledig versiebeheer
- Productieprestaties
De rapporten vanuit het veld over functionaliteit en stabiliteit zijn universeel positief. De testbatterij van SQLite is werkelijk indrukwekkend. DoltLite doorstaat deze tests, evenals een aangepaste suite van Dolt-oracle-tests. DoltLite is klaar om door jou geprobeerd te worden.
Stabiliteit van het opslagformaat
De grootste klacht over het ontwikkelingsproces van DoltLite waren de wijzigingen in het opslagformaat. Wijzigingen in het formaat waren niet achterwaarts compatibel, waardoor gebruikers op dezelfde versie moesten blijven of hun databases handmatig moesten dumpen en opnieuw importeren. Er waren 12 formaatwijzigingen nodig om bij de Beta-versie te komen. We gebruiken het huidige formaat nu al 57 releases, of meer dan drie kalendermaanden. Dit formaat lijkt een formaat waar we bij kunnen blijven.
Het opslagformaat is nu stabiel. Eventuele toekomstige ingrijpende wijzigingen zullen een ondersteund migratiepad hebben. DoltLite Beta betekent dat je het kunt adopteren zonder angst voor een brekende wijziging in het opslagformaat.
SQL-compatibiliteit
De SQL-laag van SQLite is extreem goed getest. DoltLite doorstaat het overgrote deel van deze tests eveneens, wat de SQL-compatibiliteit bewijst.
DoltLite doorstaat 100% van sqllogictest, een suite van 5,8 miljoen complexe queries. De query-laag is identiek aan die van SQLite, dus dit is verwacht.
SQLite wordt ook geleverd met een suite van 892.277 TCL-gebaseerde acceptatietests die een breder oppervlak van de SQLite-API testen. DoltLite doorstaat hiervan 99,46%, met 4.809 bekende divergenties. Voor elke divergentie moet een reden zijn vermeld. De belangrijkste redenen zijn:
- Tabellen zijn gekoppeld aan een primary key in plaats van een
rowid, om versiebeheerfunctionaliteit te ondersteunen. Sommige tests inspecteren direct de rowid.
- DoltLite maakt gebruik van chunks in plaats van pages. Sommige tests inspecteren direct de pages.
- Er is geen WAL- of journal-sidecar. WAL- en journal-tests worden overgeslagen.
SQLite-gebruikers zullen zich thuis voelen bij DoltLite. DoltLite werkt als SQLite, maar met extra versiebeheerfuncties.
Volledig versiebeheer
DoltLite implementeert de kernsuite van de Git-stijl versiebeheerfuncties van Dolt.
Lokale versiebeheerfuncties worden ondersteund, waaronder: branches, merges, diffs, rebases, cherry-picks en resets. Remote versiebeheer wordt eveneens ondersteund: push, pull, clone en fetch vanuit een aangepaste remote of DoltHub.
Je hebt zelfs de volledige Dolt Workbench GUI tot je beschikking, inclusief de agent-modus. Laat een agent los op je SQLite en gebruik dolt_reset('--hard') als hij iets verpest.
Productieprestaties
DoltLite biedt embedded database-prestaties op microseconde-schaal, maar met een "belasting" op de schrijfsnelheid vanwege het versiebeheer. De leessnelheid is bijna gelijkwaardig.
Elke nacht wordt er op GitHub een prestatierapport gepubliceerd waarin DoltLite wordt vergeleken met SQLite op basis van een standaard sysbench-stijl benchmark. Het rapport van gisteravond laat zien dat in-memory DoltLite-databases 10% langzamer zijn bij lezen en 60% langzamer bij schrijven. Databases op basis van bestanden zijn gelijkwaardig bij lezen en 10% langzamer bij gebundelde (batched) schrijfacties.
De grote uitschieter zijn kleine autocommit writes, die 3,1 keer langzamer zijn dan bij SQLite. Prestatiegevoelige DoltLite-workflows zouden zoveel mogelijk gebruik moeten maken van gebundelde schrijfacties. Zelfs voor autocommit-writes praten we over individuele schrijfprestaties in microseconden (dus onder de milliseconde): ongeveer 125 microseconden in SQLite tegenover ongeveer 400 microseconden in DoltLite op een kleine GitHub-runner.
Conclusie
DoltLite is in Beta! Het enige waar we nu nog op wachten, zijn gebruikers. Probeer DoltLite vandaag nog uit voor jouw embedded Dolt-gebruiksscenario's. Als je hulp nodig hebt, kun je terecht op ons Discord-kanaal in de #doltlite<0xF0><0x9F><0xAA><0xB6> channel.
Groetjes,