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的广告系统

F1 Query: Declarative Querying at Scale_第1张图片

 

目标,

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

高可用

并且保证ACID

F1 Query: Declarative Querying at Scale_第2张图片

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

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

 

F1 Query: Declarative Querying at Scale_第3张图片F1 Query: Declarative Querying at Scale_第4张图片

 

 

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

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

F1 Query: Declarative Querying at Scale_第5张图片F1 Query: Declarative Querying at Scale_第6张图片

 

基本架构,

F1 Query: Declarative Querying at Scale_第7张图片

 

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

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

 F1 Query: Declarative Querying at Scale_第8张图片

 

F1 Query: Declarative Querying at Scale_第9张图片

 

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

F1 Query: Declarative Querying at Scale_第10张图片

 

 

Data Model

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

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

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

F1 Query: Declarative Querying at Scale_第11张图片F1 Query: Declarative Querying at Scale_第12张图片

 

 使用Protocol Buffer

 F1 Query: Declarative Querying at Scale_第13张图片

 

索引,

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

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

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

F1 Query: Declarative Querying at Scale_第14张图片

 

 

Schema Change

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

F1 Query: Declarative Querying at Scale_第15张图片

 

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

怎么解决?

schema change算法,

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

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

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

F1 Query: Declarative Querying at Scale_第16张图片

 

 

Transaction

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

所以F1要求保证强一致性

F1 Query: Declarative Querying at Scale_第17张图片

 

F1支持如下几种事务,

Snapshot用于只读事务

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

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

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

F1 Query: Declarative Querying at Scale_第18张图片F1 Query: Declarative Querying at Scale_第19张图片

 

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

F1 Query: Declarative Querying at Scale_第20张图片

 

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

F1 Query: Declarative Querying at Scale_第21张图片

 

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

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

 

F1 Query: Declarative Querying at Scale 

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

F1 Query: Declarative Querying at Scale_第22张图片

 

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

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

F1 Query: Declarative Querying at Scale_第23张图片

 

F1的需求有哪些,

比较核心的,

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

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

 

 

架构

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

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

F1 Query: Declarative Querying at Scale_第24张图片F1 Query: Declarative Querying at Scale_第25张图片

 

查询执行

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

F1 Query: Declarative Querying at Scale_第26张图片

 

执行的过程如下,

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

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

F1 Query: Declarative Querying at Scale_第27张图片

 

DataSources

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

F1 Query: Declarative Querying at Scale_第28张图片F1 Query: Declarative Querying at Scale_第29张图片

 

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

 

你可能感兴趣的:(F1 Query: Declarative Querying at Scale)