Google onthult details over databasetechnologie Spanner

Google heeft details prijsgegeven over zijn Spanner-databasetechnologie. Spanner maakt gebruik van de zogenaamde true time-api waarbij data voorzien is van een tijdstempel. Vervolgens wordt de data verspreid over zoveel mogelijk datacenters.

De Spanner database-technologie wordt door Google in een gepubliceerde paper omschreven als een globally-distributed database waarbij data continu wordt gerepliceerd over de diverse datacenters die de zoekgigant wereldwijd in gebruik heeft. Dit replicatieproces tussen duizenden computers en zelfs datacenters verloopt volgens Google vrijwel volautomatisch om zo de reactietijden te verlagen en de load balancing te optimaliseren. Spanner zou schaalbaar zijn tot miljoenen servers over honderden datacenters, zo claimen de ontwikkelaars.

Om het replicatieproces op mondiale schaal goed te laten werken, is de true time-api ontwikkeld. Daarbij wordt elk stukje data in de database voorzien van een tijdstempel die wordt gegenereerd op basis van een atoomklok en de gps-tijdklok. Google heeft dan ook gps-ontvangers en atoomklokken in zijn datacenters staan.

Spanner is geoptimaliseerd voor applicaties die veel data lezen maar relatief weinig wegschrijven; onder andere Googles F1-advertentieplatform maakt volop gebruik van Spanner. Voor het benaderen van de database is een op sql gelijkende querytaal ontwikkeld. Verder kunnen applicaties aan Spanner aangeven in welke datacenters informatie beschikbaar moet zijn en waar niet.

Google gebruikt op grote schaal eigen technologieën, zoals het distributed file system gfs. Ook maakt het gebruik van MapReduce, een op gfs aansluitend framework dat zorg draagt voor distributed computing. Door nu ook inzicht te geven in de werking van Spanner kunnen mogelijk ook ontwikkelaars van opensource-databases hun technologie verder verfijnen.

Reacties (22)

Als het het Spanner document zo bekijk lijkt het erg op een Hadoop database waarbij replicatie naar andere datacentra wordt gedaan. een "Global" hadoop implementatie.

Hadoop is geen database; Hadoop is o.a. een distributed filesystem met daarop een API voor het uitvoeren van map/reduce jobs; verre van realtime. Dit is meer een SQL database "on steroids", waar vooral de distributie/replicatie van data aangepakt is. De eigenschappen van het queryen hierop zullen waarschijnlijk veel dichter bij dat van een klassieke relationele database zitten, alhoewel Google hier waarschijnlijk nog caches voor heeft die de vaak opgevraagde data in het geheugen cachen.

Niet helemaal waar. Hadoop is naast wat jij omschrijft ook een ecosysteem om HDFS en Hadoop MapReduce heen, met daarin vele verschillende projecten met verschillende doeleinden. Eén daarvan is HBase, welke - in tegenstelling tot standaard HDFS of bv. Hive - near-realtime random reads en random writes mogelijk zijn. HBase is gemodelleerd naar Google's Bigtable en in zeker zin lijkt Spanner idd op een geglobaliseerde variant daarvan.

Google's Spanner is totaal anders dan Google's Bigtable en dus ook HBase. Uit de paper:

Spanner has evolved from a Bigtable-like versioned key-value store into a temporal multi-version database. Data is stored in schematized semi-relational tables; (*knip*) Spanner supports general-purpose transactions, and provides a SQL-based query language.

Spanner is dus een transactionele database, geen key-value systeem zoals Bigtable. Het ondersteunen van transacties in een database die gerepliceerd is over meerdere datacentra en miljoenen servers ondersteunt is een Big Deal^tm; dat zal je niet vinden in een in-meerdere-datacentra-gerepliceerde Bigtable. Een hele hoop applicaties zijn moeilijk te implementeren zonder transacties; Spanner maakt het leven van Google-ontwikkelaars een stuk makkelijker.

Een van de redenen dat databases op deze schaal nog nooit eerder zijn gebouwd was omdat het onmogelijk leek om effcient tussen twee servers aan tegenovergestelde kanten van de wereld overeenstemming te krijgen over de volgorde waarin twee schrijf-opdrachten moeten worden uitgevoerd - de servers konden nooit met zekerheid zeggen "ik kreeg deze opdracht voor jij die opdracht kreeg". Dat kan nu wel, omdat servers zeker weten dat hun klokken gelijk lopen.

Meh, ze houden toch al een hele historie van data bij waarbij 'aangepaste' data uberhaupt al niet oude data overschrijft maar gewoon een nieuw versie nummer krijgt. Volgens mij gaat jou argument over het voordeel van transacties dus sowieso al niet echt op in Google's geval.

Overigens kan naar mijn weten een transactionele database best gebruik maken van key-value systemen.. zou het fout kunnen hebben (heb al ff niet meer met databases gewerkt) maar 'transactioneel' heeft toch enkel te maken met data locking en reversability? Dat zegt toch niks over het onderliggende gebruikte data opslag model?

Klopt, transactioneel gedrag heeft inderdaad niets te maken met het onderliggende datamodel; je zou een transactionele key-value store kunnen maken. Sterker nog, Google heeft er eentje: Megastore, gebouwd bovenop het niet-transactionele BigTable. Transactioneel zijn is op zichzelf niet zo moeilijk - de echte moeilijkheid is om transactioneel en schaalbaar te zijn, vooral in termen van het aantal schrijfoperaties dat je per seconde kunt uitvoeren. Daar zit 'm de crux, en dat is wat Spanner indrukwekkend maakt.

Google heeft transactionaliteit zeker weten nodig, anders waren MegaStore en Spanner nooit gebouwd.

Transactionaliteit is iets heel anders dan versiebeheer. "Transactioneel" beschrijft een aantal eigenschappen voor een schrijf-operatie: de zogeheten ACID-eigenschappen: Atomic (alles wordt geschreven of niets wordt geschreven), Consistent (als iets is geschreven zie je 't als je leest), Isolated (schrijfoperaties die tegelijk lopen hebben geen invloed op elkaar, of ze moeten wachten) en Durable (eenmaal geschreven blijft geschreven). Versiebeheer draait om wat er met op elkaar volgende schrijfoperaties gebeurt; de eigenschap zou je kunnen omschrijven als "als ik iets geschreven heb kan ik wat er eerst stond ook nog lezen".

Spanner biedt trouwens zowel ACID-transacties als inderdaad ook versiebeheer.

Klinkt meer als een cassandra, die werkt ook met timestamps en kan ook schalen naar zeer grote omgevingen. Mede omdat het juist lineair schaalt

Klinkt nogal in de oren als een domino omgeving. Daar wordt ook met id's gewerkt. Hoewel daar een administrator server kan worden ingezet om het gehele zwikje te coordineren. Vraag me dus wel af hoe 'nieuw' deze technologie is.

dit lijkt meer een relationele db te zijn. domino repliceert wel maar in principe niet vol continu. elke replica werkt zelfstandig en wisselt om de x min wijzigingen uit. spanner lijkt meer 1globale db te zijn verdeelt over globaal verdeelde server. het idee is kennelijk dat al die dbs continu dezelfde data bevatten.

uiteraard moest ik bij het hele replica verhaal ook wel meteen aan lotus domino denken. ik ben wel benieuwd hoe in dit spanner systeem omgegaan wordt met replica conflicten. de bovenstaande omschrijving lijkt te duiden op dat de laatste wijziging 'wint'.

In Spanner zijn er geen replica conflicten; Spanner gebruikt het Paxos protocol voor z'n schrijfwerk, waardoor de database altijd consistent is. Paxos zorgt er voor dat iedere schrijfopdracht altijd door een meerderheid van de replicas wordt uitgevoerd, pas dan krijgt de gebruiker te horen dat alles OK is. Als er daarna nog een schrijfopdracht langs komt voor hetzelfde item, dan heeft altijd een meerderheid van de servers de vorige schrijfopdracht al gedaan, dus weten ze precies wat de correcte staat van de database is.

Dat betekent dus dat er wel conflicten zijn, maar dat die automagisch worden opgelost. De enige manier om conflicten helemaal te vermijden is om maar één master te hebben in je replicatieopzet. Conflict resolution is de hoeksteen van je replicatieopzet.

Ik zou zeggen dat je er op deze manier voor zorgt dat conflicten nooit onstaan. Er is nooit een replica in een staat die later ongeldig blijkt; misschien alleen dat eentje een tijdje achterloopt. In een Paxos-systeem is er dan ook altijd een leider, een soort master, alleen kan de leiders-rol heel snel wisselen.

Maar OK, hangt af van je definitie van "conflict".

Hoeveel "nieuwe" technologie wordt er ueberhaupt ooit bedacht? De meeste nieuwe dingen zijn doorontwikkelingen van iets bestaands. Wat in ieder geval nieuw is aan Spanner is de schaal van het geheel. Als ik 'n gokje mag wagen, denk ik dat er aanzienlijk meer data in Spanner zit dan in alle Domino databases wereldwijd bij elkaar

Nieuw is dus o.a. dat dit volautomatisch gebeurd. En dat het dus mondiaal goed gaat en goed schaalt.

Interessante manier van datareplicatie. Door virtueel geen capaciteitslimiet te hebben is de replicatie tegelijk back-up en sneller bereikbaar voor een geografische locatie.
Door ook deze meta-data in alle objecten te steken blijft dit ook beheersbaar.
Dit alles op design-niveau zal dit bloedsnel maken.

Indrukwekkend, maar wat met beveiliging?

Indrukwekkend, maar wat met beveiliging?

Ja, wat met beveiliging?

vzviw is Google behoorlijk veilig (of, omdat het Google is, beheersen ze het nieuws) daar ik nooit gehoord heb van grootschalige hacks op Google's netwerken. Ruwe aanname: de datacentra zijn met elkaar in verbinding via beveiligde verbindingen (ssl, mogelijk zelfs een eigen algoritme aangezien ze daar niet vies van zijn), mogelijk hebben ze zodanig zelfs een eigen 'private' internet gemaakt.

Je zou inderdaad kunnen zeggen dat Google z'n eigen internet heeft gebouwd; als je een blik werpt op hun netwerk: http://en.wikipedia.org/w...platform#Network_topology.

Ik kan mij vaag iets herinneren van een gmail hack in china vorig jaar... maar inderdaad, ze zijn een stuk minder vaak in het nieuws dan bijvoorbeeld Microsoft, terwijl ze qua code toch een behoorlijke berg hebben (eigen OS, eigen database software, eigen bestandssysteem, ...)

Eehh Android anyone?

Wat dacht je dat hij bedoelde met "eigen OS"?

De meeste hacks op Android komen van apps die onveilig zijn en vaak buiten de Play-market om geïnstalleerd zijn (ze vragen daarna wel netjes om allerlei permissies, maar wie leest die nu he?). Daar de meeste mensen alleen de Play-market gebruiken en Google de mogelijkheid heeft om "foute software" remote van je apparaat te halen, vallen de meeste lekken dus reuze mee.

[Reactie gewijzigd door Grrrrrene op 19 september 2012 08:02]

Wat dacht je dat hij bedoelde met "eigen OS"?

Dat had ook nog Chrome OS kunnen zijn.

dat zijn allemaal externe hacks en in he geval van gmail gewoon password roof. Zoals YopY al aangeeft weten wij 'burgers' niks van gehackte google data centers.
(al geloof ik er niks van dat het niet geprobeerd wordt)