GigaOm's Stacey Higginbotham posted on Spanner: Google’s Globally-Distributed Database.
The Research Publication is published here.
Spanner is Google's scalable, multi-version, globally-distributed, and synchronously-replicated database. It is the first system to distribute data at global scale and support externally-consistent distributed transactions. This paper describes how Spanner is structured, its feature set, the rationale underlying various design decisions, and a novel time API that exposes clock uncertainty. This API and its implementation are critical to supporting external consistency and a variety of powerful features: non-blocking reads in the past, lock-free read-only transactions, and atomic schema changes, across all of Spanner.
To appear in:
OSDI'12: Tenth Symposium on Operating System Design and Implementation, Hollywood, CA, October, 2012.
Download: PDF Version
I have got a bit more time to go through the paper and I'll highlight parts I find interesting from a data center analyst perspective.
First thing caught my eye.
Applications can use Spanner for high availability,
even in the face of wide-area natural disasters, by replicating their data within or even across continents. Our
initial customer was F1 , a rewrite of Google’s advertising backend. F1 uses ﬁve replicas spread across
the United States.
What is F1?
And how does this relate to Spanner?
Google has 3 to 5 data centers in a geographic region.
Why 5, not just 3?
I had just written about Google's move to Chile had three more. So, need to get used to looking for 5 Google data centers to support a geographic reason with 100ms latency, not just three.
I could go longer into the document, but I think the post will get too long. Let's just stop with one point that is useful in looking at these two documents. Google has 5 data centers within 100ms in a geographic region to support ad business which is where they make most of their money.