Paper http://nil.csail.mit.edu/6.824/2020/papers/spanner.pdf

Lecture https://www.youtube.com/watch?v=4eW5SWBi7vs

Spanner Docs https://cloud.google.com/spanner/docs/true-time-external-consistency#faq

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

Spanner shards it’s data across many sets of Paxos state machines in datacenters spread all over the world so 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.

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; data is versioned, and each version is automatically timestamped with its commit time old versions of data are subject to configurable garbage-collection policies; and applications can read data at old timestamps.

Spanner also supports general-purpose transactions, and provides a SQL-based query language. It has two very interesting features

  • Applications can specify constraints to control which Datacenters contain which data how far data is from its users (to control read latency), how far replicas are from each other (to control write latency), and how many replicas are maintained (to control durability, availability, and read performance). Data can also be dynamically and transparently moved between datacenters by the system to balance resource usage across datacenters.

  • Spanner provides Externally Consistent reads and writes and globally-consistent reads across the database at a timestamp

These features enable Spanner to support consistent backups, consistent MapReduce executions and atomic schema updates, all at global scale even in the presence of ongoing transactions.

External consistency

https://cloud.google.com/spanner/docs/true-time-external-consistency

External consistency is a stronger property than linearizability, because linearizability does not say anything about the behavior of transactions. Linearizability is a property of concurrent objects that support atomic read and write operations. In a database, an “object” would typically be a single row or even a single cell. External consistency is a property of transaction-processing systems, where clients dynamically synthesize transactions that contain multiple read and write operations on arbitrary objects. Linearizability can be viewed as a special case of external consistency, where a transaction can only contain a single read or write operation on a single object.

This is different from serializability where even though the customer executed T1 and then T2 sequentially, the system would be permitted to reorder them, which could cause the debit to incur a penalty due to insufficient funds.

External consistency guarantees that if transaction T1 commits before transaction T2 starts, then T2 will see the effects of T1 regardless of what replica it executes on, This means that serializability and external consistency in a single-node database is the same since committing a transaction on a single-node database makes it visible to every transaction that starts after it.