By 2010, Google had two kinds of storage and wanted a third. Bigtable scaled to enormous datasets, but it had no transactions across rows and only eventually consistent replication between data centres. Megastore added synchronous replication across data centres and a friendlier, schema-based data model, and the Spanner paper says at least 300 applications used it despite its poor write throughput. And the advertising backend, the business that paid for everything, ran on MySQL sharded by hand, tens of terabytes of it. The last resharding of that database had taken over two years of effort across dozens of teams.
What Google wanted was a database that felt like SQL, with real transactions that could touch any rows anywhere, replicated across continents, scaling like Bigtable. The hard part isn't any one of those. It's getting all of them at once without the transactions turning into a global traffic jam. Spanner's answer rests on an unusual idea: instead of pretending clocks agree, measure exactly how much they might disagree, and wait that long.
The paper: Spanner: Google's Globally-Distributed Database, Corbett et al., OSDI 2012, Google.
The shape of the system
A Spanner deployment is called a universe, divided into zones: roughly, a set of servers in one data centre. Each zone has a zonemaster that assigns data to between a hundred and several thousand spanservers, plus location proxies that tell clients which spanserver holds their data.
Each spanserver manages between 100 and 1,000 tablets. A tablet is a lot like a Bigtable tablet: a set of (key, timestamp) → value mappings, stored as B-tree-like files plus a write-ahead log on Colossus, Google's successor to GFS. Because every value carries a timestamp, Spanner is a multi-version database, like the MVCC engines you met in Module 20, but with versions that mean something across the whole planet.