Google Spanner and Postgres-XC

Reading through Google's Spanner paper, I can't help but see the parallels to Postgres-XC. Although the two solutions tackle different problem sets, the fact that they are both distributed databases with the goal of providing consistency out to the client, results in very similar architectures. Take for example the first paragraph in the abstract of the paper. If you change just a few words, it does a great job of describing what Postgres-XC can do:

Postgres-XC is PostgreSQL’s scalable, multi-version, distributed, and synchronously-replicated database. It is the first system to distribute data at scale and support externally consistent distributed transactions. This paper describes how Postgres-XC is structured, its feature set, the rationale underlying various design decisions, and a novel Global Transaction Manager. This Manager 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 Postgres-XC.

One of the key differences is how concurrency control is managed. In Postgres-XC, this is all handled by the Global Transaction Manager which supply things like transaction ids. Since Spanner is globally distributed and contacting a single process to get the necessary transaction ids is a real drain on performance, they take the route of using timestamps. They keep the clocks synchronized geographically through the use of GPS and atomic clocks. This method isn't exact and Google claims less than 10ms of uncertainty, which is fine for many applications, but not all. The real interesting part is how Spanner handles multi-version concurrency control. Spanner uses a concept of TT.before and TT.after to determine which version of a tuple the client will see. That sounds a lot like the concept of xmin and xmax in PostgreSQL and Postgres-XC.

© 2013 StormDB. All rights reserved. Developed by Aspire Solutions