Googles Cloud Spanner lover at blande det bedste fra nosql og relationelle databaser

Google egen distribuerede database understøtter stadig SQL, men redundante servere kan udnyttes aktivt, forklarer Urs Hölzle, chef for teknisk infrastruktur hos Google Cloud. Illustration: Google
Google bruger selv databasen til at skalere selskabets egne tjenester på globalt niveau. Ultrapræcise tidsstempler er afgørende.

SAN FRANCISCO: Ifølge Google vil man nu kunne få det bedste fra to verdener, eller i hvert fald det bedste fra to typer af databaser. Google har nemlig lanceret Cloud Spanner, som bygger på Googles egen database, der er udviklet til at skalere globalt.

»Det har været et klassisk problem inden for databaser. Det er svært at skalere en relationel database ved at fordele den på flere datacentre. Så kan man bruge nosql-databaser, men så mister man consistency,« sagde chef for teknisk infrastruktur hos Google Cloud, Urs Hölzle, på konferencen Google Cloud Next, som netop er blevet afholdt i San Francisco.

Consistency dækker over, at man skal kunne være sikker på, at data i databasen altid er lige præcis det, de skal være på et givent tidspunkt.

Det kan være vanskeligt, når man skalerer en database, så den bliver fordelt på flere datacentre. Traditionelle relationelle databaser sikrer consistency, men det kan blive en flaskehals på ydelsen, når man distribuerer databasen.

Nosql-databaser kan til gengæld nemt skaleres, men det bliver vanskeligere at sikre, at data altid er konsistente. Det kan eksempelvis være et billetsystem, hvor man ikke skal kunne sælge den samme billet to gange.

Atomure i alle datacentre

Googles Cloud Spanner er en mellemting, for det er muligt at benytte helt traditionel SQL med databasen, og den har også en relationel struktur. Men den er samtidig bygget til at være distribueret.

Til at opretholde consistency har Google udviklet ekstra præcise tidsstempler, som holder styr på alle transaktioner.

»Det kræver en utrolig præcis tidsstempling, så vi har placeret atomure i alle vore datacentre,« siger Urs Hölzle.

Med muligheden for at distribuere sin database vil man også kunne sikre høj oppetid. Spanner fungerer ifølge Urs Hölzle ved, at man har et ulige antal kopier, typisk 5 eller 7, af databasen. I modsætning til en traditionel database, så er der ikke tale om replikering mellem en primær og en sekundær kopi.

Alle kopier af Spanner er aktive, og det er altid et flertal af kopierne, som bestemmer tilstanden og skal godkende en transaktion. At alle kopierne er aktive giver en bedre udnyttelse af hardwaren end et klassisk setup med en primær og sekundær server.

»Alle noderne er aktive, så du kan bruge alle nodernes hardware til at give dig mere ydelse. Du har stadig 2 ud af 5, som reelt kun er der som sikkerhedsnet, men du kan udnytte deres kapacitet,« forklarer Urs Hölzle.

Virker kun hos Google

Der er dog også visse fodnoter, man bør bemærke. Spanner er udviklet til at understøtte Googles egne tjenester og har de senere år understøttet flere hundrede tjenester i Googles egen drift.

Men Cloud Spanner er ikke open source. Den ligger indtil videre udelukkende på Googles Cloud Platform, så der er altså potentielt tale om, at man binder sig til Googles platform.

»Der er et open source-projekt, Cockroach DB, som er inspireret af den teknologi, vi har beskrevet i vores oprindelige paper om Spanner. Det er startet af tidligere Google-folk. Vi er endnu ikke blevet enige om et fælles API, men det vil vi meget gerne nå frem til,« siger Urs Hölzle.

Når Google ikke gør Spanner til open source, så hænger det ifølge Urs Hölzle sammen med, at Spanner er meget tæt knyttet til den måde, hvorpå Google har opbygget sin platform.

»Du skal have atomure i dit datacenter, så det vil ikke umiddelbart virke for alle,« forklarer han.

Version2 er inviteret til Google Cloud Next af Google.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (1)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Morten Bøgh

Google vil ikke helt røbe hvordan det her virker, fordi det kun er dem selv der kan få det til at virke... Ja, hvad skal vi andre så med det, ud over at blive imponeret over hvad Google dog kan, hvor er de dog dygtige... Yderligere er det ligesom at fremstillingen skifter emne undervejs: Det starter med at SQL-databaser ikke kan distribueres. Hvilket er et korrekt og væsentligt faktum. Nosql-databaser kan distribueres hvilket også er korrekt og interessant. Men henimod slutningen af fremlæggelsen bliver det til noget helt andet: At Google kan få en replikeret SQL-base til at virke ved at holde meget godt styr på tiden, og sørge for at antallet af kopibaser er ulige... Jamen det kan vi andre også, det er ingen kunst at replikere en SQL-database, selv uden atomure og ulige tal, men det gør den altså ikke til en distribueret database. Amazon kører med en distribueret database, og kan derfor udmærket sælge den samme bog to gange. De kan ikke – på tværs af partitioner – holde præcist styr på hvor mange eksemplarer af bogen der er tilbage. Løsning af det problem kræver mere magi end hvad man kan opnå med atomure og ulige tal. Det er nogle informationer der skal deles mellem alle partitioner, og hvis dette er opfyldt, så er vi der hvor Googles fremlæggelse ender: Vi har en replikeret database og der er ikke længere tale om en distribueret database. Der er en ikke-passerbar kløft mellem de to teknologier. Det minder (undskyld mig) om den selvkørende bil, hvor der tilsyneladende er tale om at Google kan ophæve Newtons love i kraft af deres imponerende intelligens og dygtighed.

  • 2
  • 0
Log ind eller Opret konto for at kommentere