F1: A Distributed SQL Database That Scales

构建在spanner上, 提供synchronous cross-datacenter replication和强一致性.

同步复制带来的高commit延时, 通过数据模型的结构特点缓解(how?).

• 目标/挑战

  • 扩展性

    • 很多复杂查询(join,), 对shard策略要求高

  • 高可用

  • 一致性

    • ACID

  • 易用性

    • 完全兼容sql

架构

• client就近连接相同dc的F1 server

• 依赖spanner进行跨dc的通信

  • CFS做本地存储

• F1 server基本无状态

  • 除了client拿到悲观锁时, 事务期间, 这个client会始终访问开始事务时的F1 server.

• query planner 还会评估请求是否应该分布式执行.(是否会降低请求处理时间)

• 扩展

  • 加Spanner server

    • 会导致数据重分布, 但是对F1/client透明

  • 加F1 server

  • 加F1 slave

• spanner跨机房的平均延时(50 ~ 150ms)

• spanner

  • 数据组织

    • Group, 复制的基本单位, paxos算法做复制. 副本叫tablet. 所有写(tx)都在paxos选出的leader上进行.可能有只读副本, 不参与选举.

      • Fragment

        • Directory

          • Row

  • 事务

    • 乐观事务

      • 相同group事务

      • 跨group事务

        • 2pc-commit

    • 时序

      • globally safe timestamp

数据模型

支持Hierachical Schema, 模型定义时, 可以继承父模型, 父模型的字段会插入子模型中. 类似于一些orm(sqlalchemy), 中定义类, 子类最终形成表的逻辑.

• Customer(customerId)

  • Campaign(customerId, campaignId)

    • AdGroup(customerId, campaignId, adGroupId)

好处是可以提高部分查询的并行度, 例如Campaign.FindByCustomerId(xx), 可以并行查询customer和campaign, 因为customerId相同.

另外层级结构, 是的一些相同祖先的数据操作, 可以集中在spanner的一个group上,避免了跨group的2pc过程.

列支持pb格式, (支持pb结构内查询么? 支持构建索引时从pb里抽字段)

索引

F1索引有两种物理布局: (这里local,global主要是区分spanner机器)

• local

  • 必须包含根节点id

    • (customerId, keyword)

      • 保证这些index存到相同的spanner机器

• global

  • 不用包含根节点id

  • 会导致大的事务无法完成, 因为对index的变更需要非常多的2pc参与者,导致无法协商完成.

schema变更