Sammenligning af Google Megastore

En lille bunke Googlere nylig forelagt et dokument, \ "Megastore: Forudsat Scalable, høj tilgængelighed Storage for Interactive Services \" (PDF), at detaljer opbygningen af ​​en større distribueret database, som anvendes på Google.

Megastore \ "er blevet bredt anvendt i Google i flere år ... håndterer mere end tre milliarder skrive og 20 milliarder læs overgange dagligt ... [og] gemmer næsten en petabyte ... på tværs af mange datacentre. \"

Andre har allerede opsummeret papiret ([1] [2]), så jeg vil fokusere på min reaktion på det. Hvad jeg fandt overraskende om Megastore, især når man sammenligner med andre store databaser, er, at det favoriserer konsistens over ydeevnen.

For konsekvens, giver Megastore \ "fuld ACID semantik inden partitioner \", \ "understøtter to-fase begå tværs enhed grupper \", garanterer, at læser altid se de sidste skriver, bruger Paxos for bekræftelse enighed blandt replikaer, og bruger fordelt låse mellem \ "koordinator processer \" som en del af afsløre fejl. Dette er alle usædvanligt stærke forhold til de mere afslappede eventuel sammenhæng tilbydes af databaser som Amazon's Dynamo, Yahoo's HBase, og Facebooks Cassandra.

Problemet med at give Megastore niveau af konsistens er performance. Papiret meste beskriver Megastore's resultater i det solrige termer, men når man ser på detaljerne, er det ikke tåler sammenligning med andre databaser. Megastore har \ "gennemsnitlig læse ventetid på snesevis af millisekunder \" og \ "gennemsnitlig skrive ventetid på 100-400 millisekunder \". Derudover har Megastore en grænse på \ "et par skriver pr sekund pr enhed gruppe \", fordi højere skriver satser vil medføre konflikter, forsøg, og endnu værre resultater.

Til sammenligning forventer at komme 4ms læser og 5 ms skriver på deres database, så Megastore er en størrelsesorden eller to langsommere, end hvad komme udviklere synes at være villig til at tolerere.

Google applikationsudviklere synes at finde den ventetid, der skal en bøvl så godt. Papiret fortæller, at Googlere finde den ventetid \ "acceptabel \", men ofte er nødt til at \ "skjule skrive latenstid fra brugere \" og \ "vælge enhed grupper omhyggeligt \".

Det gør mig gad vide, om Google har gjort det rigtige afvejningen her. Er det virkelig nemmere for applikationsudviklere at beskæftige sig med høj latenstid hele tiden end til næsten altid have lav latency, men er nødt til at bekymre sig mere om sammenhængen spørgsmål? De fleste store databaser har gjort valget den anden vej. Helt overraskende.

Update: Googler DeWitt Clinton skriver med en god pointe:. \ "Vi bygger oven på Megastore, når vi kræver nogle af disse egenskaber (tilgængelighed, sammenhæng), og at Bigtable direkte, når vi kræver lav ventetid og høj i stedet Så det er op til ansøgningen for at afgøre, hvad kompromiser at gøre, absolut ikke one-size-fits-all. \ "