Stel je voor dat je een enorme, chaotische bibliotheek probeert te organiseren waar miljoenen mensen tegelijkertijd boeken proberen te lenen, te lezen en te herschrijven. In de wereld van de informatica is dit de uitdaging van databases: systemen die informatie opslaan zodat applicaties deze direct kunnen vinden en aanpassen. Decennialang was de grote vraag hoe deze bibliotheken konden groeien om het hele internet aan te kunnen zonder in te storten. De oude manier was als het hebben van een enkele bibliothecaris die elk boek moest stempelen, wat een lange rij veroorzaakte die alles vertraagde. De nieuwere, "eventual consistency"-manier was als het laten raden door mensen wat er in het boek stond en het later corrigeren van de fouten, wat snel is maar riskant als je nú de waarheid nodig hebt. Het doel van moderne database-engineering is om een systeem te bouien dat net zo snel is als de gokmethode, maar even betrouwbaar als de stempelmethode, in staat om miljoenen transacties per seconde te verwerken zonder dat iemand ooit handmatig de planken hoeft te beheren.

Dit artikel introduceert Aurora DSQL, een nieuw soort database ontworpen door Amazon Web Services om precies dit probleem op te lossen. Denk aan een superintelligent, zelfrijdend bibliotheeksysteem dat onmiddellijk kan uitbreiden of krimpen afhankelijk van hoeveel mensen er op bezoek komen. De auteurs hebben een systeem gebouwd dat het "denken" (het uitvoeren van de SQL-code) scheidt van de "opslag" (het bewaren van de boeken) en de "regels" (erop toezien dat niet twee mensen tegelijkertijd dezelfde pagina aanpassen). Door gebruik te maken van een speciale "Journal" die fungeert als een permanente, onveranderlijke dagboekregistratie van elke wijziging die is aangebracht, stelt DSQL verschillende onderdelen van het systeem in staat om onafhankelijk van elkaar te werken. Het artikel laat zien dat dit ontwerp de database laat schalen van nul gebruikers naar miljoenen transacties per seconde, over verschillende continenten werkt zonder te vertragen, en gegevens perfect consistent houdt, zodat je je nooit zorgen hoeft te maken over het lezen van een boek dat iemand anders op dat moment aan het herschrijven is.

De Magie van de Ontkoppelde Bibliotheek

Om te begrijpen hoe Aurora DSQL werkt, stel je een gigantische bibliotheek voor waar de bibliothecarissen, de boekenplanken en de regelhouders zich allemaal in verschillende gebouwen bevinden, verbonden door supersnelle telegrammen. In oudere systemen waren deze onderdelen aan elkaar vastgelijmd; als de planken te vol raakten, moest de hele bibliotheek stoppen en reorganiseren. DSQL haalt ze uit elkaar.

Ten eerste zijn er de Query Processors. Dit zijn de bibliothecarissen die met je praten. Wanneer je om een boek vraagt, dragen zij de zware boeken niet zelf. In plaats daarvan draaien ze binnen kleine, beveiligde virtuele kamers genaamd Firecracker MicroVM's. Deze kamers zijn zo efficiënt dat ze in een oogwenk kunnen worden gecreëerd of vernietigd. Als je een plotselinge toestroom van bezoekers hebt, bouwt het systeem onmiddellijk meer kamers. Als de drukte afneemt, breekt het ze af zodat je niet betaalt voor lege ruimte. Dit is het "serverless"-gedeelte: je beheert de bibliothecarissen niet; ze verschijnen gewoon wanneer je ze nodig hebt.

Vervolgens zijn er de Storage Nodes. Dit zijn de boekenplanken. Ze bevatten niet de hele bibliotheek; ze bevatten alleen specifieke secties van boeken op basis van een "shard key" (zoals het sorteren van boeken op de eerste letter van de auteur). Omdat de bibliothecarissen en de planken gescheiden zijn, kunnen de bibliothecarissen hun eigen gang gaan zonder te wachten tot de planken bij zijn. Ze lezen van de dichtstbijzijnde plank in hun eigen buurt (Availability Zone), wat het lezen ongelooflijk snel maakt.

Ten slotte zijn er de Adjudicators en de Journal. De Adjudicators zijn de regelhouders die beslissen of een wijziging is toegestaan. De Journal is het meesterdagboek. Wanneer je een boek wilt veranderen (een "write"), schrijft de bibliothecaris de wijziging op een stuk papier, maar plaatst het nog niet op de plank. Ze sturen het naar de regelhouder. De regelhouder controleert of iemand anders op datzelfde moment hetzelfde boek probeert te veranderen. Als het duidelijk is, schrijft de regelhouder de wijziging in de Journal. Deze Journal is het belangrijkste onderdeel: het is een permanente, geordende lijst van elke wijziging die ooit heeft plaatsgevonden. Zodra iets in de Journal staat, is het voor altijd veilig, zelfs als de planken of de bibliothecarissen verdwijnen.

De "No-Wait" Lees-Truc

Een van de coolste trucs in dit artikel is hoe het met lezen omgaat. In veel databases moet je wachten tot de bibliothecaris heeft gecontroleerd of er niet iemand aan het schrijven is in het boek dat je wilt lezen. Dit veroorzaakt wachtrijen en vertragingen. DSQL gebruikt een slimme tijdreis-truc genaamd Multi-Version Concurrency Control (MVCC).

Stel je voor dat elke keer dat een boek wordt gewijzigd, de bibliotheek de oude versie niet wist. In plaats daarvan maken ze een nieuwe kopie aan met een tijdstempel. Wanneer je om een boek vraagt, vraag je niet om "het boek"; je vraagt om "het boek zoals het was om 14:00 uur". Het systeem vindt dan de versie die geldig was om 14:00 uur. Omdat het systeem gebruikmaakt van superprecieze klokken (nauwkeurig tot microseconden), weet het precies welke versie het aan je moet tonen. Dit betekent dat je een boek kunt lezen terwijl iemand anders een nieuwe versie aan het schrijven is, en je ziet hun rommelige, half afgemaakte wijzigingen niet. Je ziet een perfect, bevroren snapshot van het verleden. Dit maakt het mogelijk dat miljoenen mensen tegelijkertijd lezen zonder elkaar ooit te blokkeren.

De Multi-Region Superkracht

Het artikel pakt ook het probleem van afstand aan. Meestal, als je een bibliotheek in New York en een in Londen hebt, duurt het synchroniseren van deze bibliotheken tijd vanwege de lichtsnelheid. Als je probeert een boek op beide plaatsen tegelijkertijd bij te werken, moet je wachten tot een bericht de oceaan overgestoken heeft, wat alles vertraagt.

DSQL lost dit op door active-active te zijn. Dit betekent dat je een bibliotheek in New York en een bibliotheek in Londen kunt hebben, en beide zijn tegelijkertijd volledig open voor zaken. Wanneer je een wijziging maakt in New York, schrijft het systeem deze naar de Journal. De Journal stuurt vervolgens een kopie naar Londen. De magie is dat dit slechts één keer gebeurt, op het exacte moment dat je op "commit" (voltooien van de transactie) drukt. Het systeem voorkomt je niet bij het lezen of schrijven terwijl het bericht onderweg is. Het gebruikt een "quorum"-systeem, wat betekent dat het slechts bevestiging van de wijziging in twee van de drie regio's nodig heeft om het als veilig te beschouwen.

Het artikel heeft dit gemeten en kwam tot de conclusie dat, zelfs met de afstand tussen Virginia en Oregon (ongeveer 62 milliseconden round-trip), het systeem die "afstandstaks" slechts één keer per transactie betaalt. Voor het lezen is het zelfs sneller, omdat je leest van de lokale bibliotheek. De auteurs laten zien dat dit ontwerp de database in staat stelt om snel en consistent te blijven, zelfs als een hele regio (zoals een hele stad) offline gaat door een ramp.

De Regels van het Spel

De auteurs waren zeer zorgvuldig over wat ze beloofden. Ze kozen voor Snapshot Isolation, een specifieke set regels voor hoe transacties zich gedragen. Het is alsof je zegt: "Je kunt het boek lezen zoals het was toen je begon met lezen, en je kunt het veranderen wanneer je klaar bent, maar als iemand anders het in de tussentijd heeft veranderd, moet je het opnieuw proberen." Dit is anders dan striktere regels die je zouden dwingen te wachten op een lock, wat de boel vertraagt.

Het artikel sluit expliciet de gedachte uit dat je een enkele "leader" nodig hebt om alles te beheren. In veel systemen is één computer de baas, en als die kapot gaat, stopt alles. DSQL heeft geen enkele baas. Elk onderdeel kan opschalen of afschalen, en als een onderdeel faalt, gaan de anderen gewoon door. Het artikel sluit ook de gedachte uit dat je de hardware zelf moet beheren. Het systeem handelt de "hitte" (welke delen te druk worden) automatisch af. Als een sectie van de bibliotheek te druk wordt, splitst de control plane (de bibliotheekmanager) deze automatisch in twee kleinere secties en verplaatst enkele boeken naar een nieuwe plank, allemaal zonder dat jij er iets aan hoeft te doen.

Het Testen van de Theorie

De auteurs hebben niet alleen gegokt dat dit zou werken; ze hebben het intensief getest. Ze gebruikten een methode genaamd deterministische simulatie, waarbij ze het systeem draaiden in een computerprogramma dat miljoenen fouten, netwerkvertragingen en crashes kon simuleren in een fractie van een seconde. Ze ontdekten dat het systeem deze fouten kon afhandelen zonder gegevens te verliezen of in de war te raken.

Ze hebben ook real-world tests uitgevoerd (zoals de TPC-C benchmark, die een drukke winkel simuleert). De resultaten lieten zien dat DSQL kon opschalen van een cold start (waarbij het zeer weinig middelen heeft) naar het verwerken van miljoenen operaties per minuut. Het duurde ongeveer 25 minuten om vanaf een volledig lege staat naar volle snelheid op te warmen, maar zodra het "warm" was, was het ongelooflijk snel. Het artikel merkt op dat hoewel ze zeer vertrouwen hebben in deze resultaten, ze nog steeds werken aan het toevoegen van meer functies zoals foreign keys (die tabellen aan elkaar koppelen) en stored procedures.

De Kern van het Verhaal

Aurora DSQL is een bewijs dat je het beste van twee werelden kunt hebben: een database die net zo gemakkelijk te gebruiken is als een eenvoudige service (waar je niets beheert) en even krachtig als een massaal, globaal systeem. Door het denken, de opslag en de regels te scheiden, en door een permanente journal te gebruiken om de tijd bij te houden, stelt het applicaties in staat om te groeien van nul naar miljoenen transacties zonder moeite te doen. Het is een systeem ontworpen voor een wereld waar dingen snel veranderen, waar rampen gebeuren, en waar je moet weten dat de informatie die je leest de absolute waarheid is, op dit moment.