Review of "F1: A Distributed SQL Database That Scales "

14 Oct 2015

Review of "F1: A Distributed SQL Database That Scales "

Previously, the AdWords system uses a sharded MySQL as the backend system. But sharding has several issues. First, it's not transparent, so it incurs extra burden onto developers; Second, some shard server might get very hot, in which case you need to manually reshard the database, which is very complicated; And cross shard query is very difficult, and cross shard transaction is not supported at all. So sharded RDMS is really not a solution for large scale systems like AdWords. Then how about NoSQL systems like BigTable, it turned out that these systems also has its own problems, even though they do provide high availability and scalability. BigTable doesn't have a full fledge transactions support; It doesn't have secondary index, and no SQL query support, which is very import for relatively complex business logic; Also it doesn't provide joins and as a consequence results in a lot of data islands. So the engineers developed F1, which has both the usability and transactions support of traditional RDMS and the scalability and availability of NoSQL systems. It's also designed to support both OLTP and OLAP scenarios.

F1 is built on top of Spanner, a distributed, highly scalable storage systems. As Spanner controls the storage of all the data, one key design decision of F1 is it doesn't hold any data. So all data is remote, F1 just acts as an orchestration layer on top of Spanner, providing all the RDMS features. This makes F1 not able to leverage data locality, but on the other hand, makes the implementation simpler. It has several ways to mitigate the disadvantage of having no local data. Hierarchical schema makes a read efficient, because data you usually need at the same time is stored in one Spanner bucket, and it also enables parallel fetching and single range read. Protocol buffer types support also makes it really efficient to do small table joins.

As Spanner uses synchronous replication mechanism, the latency of the system is relatively high. But as it uses a lot of hash repartitioning and optimized distributed query technique, the performance of performing complex queries is actually better than the sharded MySQL, and the availability and scalability is much better!

Besides these, F1 also has some creative features like ChangeHistory PubSub system, nonblocking schema update, etc. I think it really proves that you can have both usability of traditional RDMS and scalability and availability of NoSQL systems all at the same time. So I think it'll be influential paper in 10 years.