F1 Query: Declarative Querying at Scale

F1相关的论文两篇，

F1: A Distributed SQL Database That Scales

F1 Query: Declarative Querying at Scale

 

F1: A Distributed SQL Database That Scales

F1是一个Globally-distributed的数据库系统，用于替换传统的Sharded Mysql，用于Google的广告系统

 

目标，

可以简单scaleup，传统的sharded mysql，扩容是很麻烦的，因为要重新分shard

高可用

并且保证ACID

这篇文章的主要贡献，为了达到这些目标，做的trade-off和sacrifices

F1是架构在Spanner上，所以可扩展存储，同步副本，强一致性，全局有序这些事由spanner保证的，那么其实对于F1而言设计就可以比较轻了

 

 

 

F1做了存储分离，分布式的设计，自然和传统Sharded Mysql比，latency会增加并难以控制，

F1解决延迟的方法，主要是两个，一个是hierarchical关系表，一个是大量使用batch，并行和异步

 

基本架构，

 

F1 server作为查询引擎，和Spanner和CFS是分离的，但为了就近查询，部署的时候这些系统是co-located

最关键的，F1 server是无状态的，这样就可以随意scale up

 

 

 

 F1，有一个slave pool，由master管理，普通的查询用不到，但是如果需要使用分布式查询的时候，那么就需要用slave pool里面的F1 processes扩大并行度

 

 

Data Model

前面说了，F1为了避免延迟不稳定的问题，提出的解决方案

Hierarchical Schema，看右边的图，其实很容易理解，就用冗余，去范式化

这样的好处，避免join；数据会clustered，这对分布式数据库很关键；update成本低，因为数据都clustered在一起

 

 使用Protocol Buffer

 

 

索引，

独立的索引表，事务性的，强一致性

index分为local和global，全局索引和row无关，如果大的事务需要更新大量的全局索引，一定会影响查询性能，因为也要保证索引的事务性

这里的建议，少用global索引，尽量用小事务

 

 

Schema Change

SchemaChange的难点主要是因为，对于分布式数据库，如何保证原子性和同步；如何保证change的过程中，不影响读写和可用性

 

F1说为了避免影响可用性，一定要异步，但是异步就会导致不一致，同时不同的F1server会用不同的shema更新数据库

怎么解决？

schema change算法，

首先，保证同时最多只有两个schema active，并且没有schema都有lease，哪怕网络不通，过期后无法使用

再者，把schema change切分成multiple phase，保证phase之间是没有冲突的

这里没有太详细说，参考reference

 

 

Transaction

这里提出，最终一致性，对于应用的开发者的负担是很重的，因为需要很多逻辑去处理各种错误，乱序，迟到的数据

所以F1要求保证强一致性

 

F1支持如下几种事务，

Snapshot用于只读事务

悲观事务，直接用Spanner就可以

乐观事务，F1默认使用，每一行都有一个隐藏column存最新的commit更新时间，每次返回row的时候会带上，

这样client再次commit的时候，会开一个小事务去check更新时间是否发生变化

 

乐观锁的好处不言而喻，坏处，

 

并且这里的行锁，也可以变成column级别，更细粒度的锁

 

本篇最关键的是，F1是构建在Spanner之上的，存储和计算分离，所以把复杂的部分放到存储，F1是无状态的，所以他说的，Scaleup，可用性，一致性就都已经解决了；

然后再分享一些经验，包含data model，schema change，事务等

 

F1 Query: Declarative Querying at Scale 

F1 Query提出了数据库系统的理想形式，cover大家对于数据库的所有需求，太牛逼了，如果不是google提的，一定会被人骂

 

F1 query是上一篇F1的进化版本，

区别在于，更彻底的，federated query引擎，兼容更多的data source；而F1只是读，Spanner和Mesa的数据

 

F1的需求有哪些，

比较核心的，

数据是碎片化的，存在很多存储系统里面

云原生架构，存储和计算分离，带来的问题是，latency的high variance

 

 

架构

其实这篇论文的主要内容在overview就已经讲完了

他不是发明了一种引擎来解决所有的问题，而是把之前所有的方案集成到一个db里面

 

查询执行

查询的执行考虑到就近原则，哪怕google的网络很牛逼，近些还是快的

 

执行的过程如下，

SQL parse，优化，生成物理执行计划后，

和普通的执行不一样，这里先要区分是Interactive执行，还是Batch执行

 

DataSources

对于多种datasources，需要提供一种关系型的抽象，像Hive一样，右边是例子，

 

 论文后面还讲了一些细节，但没有太多特别的东西，有兴趣的可以看看