F1和Spanner整体比较

2022-06-02 00:00:00 索引 查询 数据 服务器 延迟

有了F1和Spanner的论文，现在就可以全面了解它们之间的相互作用了。因此，让我们从回顾两个系统的关键目标开始。


F1设计的关键目标

  • 系统必须能够通过添加资源进行扩展
  • 无需应用程序更改即可重新分片和重新平衡数据的能力
  • 交易的ACID一致性
  • 全面的SQL支持，支持索引

    Spanner的目标
  • 主要重点是管理跨数据中心复制的数据
  • 重新分片和重新平衡数据的能力
  • 自动跨机器迁移数据

F1 –概述

  • F1建立在Spanner之上。Spanner支持以下功能：–通过分布式事务（2PC）的强一致性，基于时间戳的全局排序，通过Paxos的同步复制，容错，数据自动重新平衡等。
  • F1为此添加了诸如
    • 具有对外部数据执行联接功能的分布式SQL查询
    • 索引的交易一致性
    • 异步架构更改
    • 使用新的ORM库

F1的架构

  • 用户通过客户端库进行交互
  • 任何服务器都可以接收SQL查询请求
  • F1客户端的请求通过负载均衡执行，该负载均衡倾向于保持较低的延迟。因此，除非另有必要，否则它将尝试将请求转发到同一/近数据中心中的F1服务器。
  • F1服务器一般与Spanner服务器相同的数据中心中。
  • Spanner服务器又从Colossus文件系统（GFS的后继）获取数据
    • 每个Spanner服务器都使用称为Tablet的存储抽象。通常负责100到1000个Tablet实例。Tablet的数据存储在一组B树之类的文件和一个WAL日志（write ahead log）中。这些文件位于CFS上。
    • 每个Spanner服务器还在Tablet顶部实现一个Paxos状态机。
  • F1服务器大多是无状态的。它们不保存任何数据，因此无需任何数据移动即可轻松添加或删除。
  • F1流程以主从方式组织。F1客户端查询请求委派给F1从服务器。
  • F1 Slave服务器池成员身份由F1主服务器维护。
  • 可以通过增加F1主站，F1从站和跨区服务器的数量来增加系统的吞吐量。
  • 数据存储由Spanner管理。
    • Spanner将数据行划分为一个称为目录的存储桶抽象（目录是一组共享公共前缀的连续键）。模式中的父子关系是使用目录实现的。
    • 添加新的跨度服务器将导致跨Spanner Tablet重新分配数据，但不会影响任何F1服务器。同样，此过程对F1服务器是透明的。
    • 由于数据跨地理分布广泛的多个数据中心同步复制，因此提交等待时间相对较高（50-150 ms）。
  • 该系统还具有不参与Paxos算法的只读副本。只读副本仅用于快照读取，因此可以隔离OLTP和OLAP工作负载。

数据模型–分层架构

  • 在逻辑级别F1的数据模型类似于RDBMS。此外，F1中的表可以组织成一个层次结构。
  • 与层次结构中的Root表相对应的行称为根行。
  • 与根行相关的子表行存储在一个Spanner目录中。
  • 客户端应用程序通过INTERLEAVE IN声明在数据库模式中声明层次结构。
  • 目录表中具有键K的每一行，以及后继表中以字典顺序以K开头的所有行，都构成一个目录。
  • 从物理上讲，每个子表都与其父表的行聚在一起并交织在一起。
  • 该论文继续强调了拥有用于读写的分层模式的一些好处。但是，在F1中，分层建模不是必需的。平面架构也是可能的。
  • F1中的索引是事务性的，并且完全一致。索引在Spanner中存储为单独的表，由索引键和索引表的主键的串联键输入。
  • 它使用两种类型的物理存储布局–本地和全局

F1中的查询处理
观察到F1中的查询处理与我们在近的SQL-on-Hadoop解决方案（例如Cloudera的Impala，Apache Drill和之前的产品）中没有发现任何共享并行数据库的情况非常相似，这并不奇怪。
查询的生命周期

  • 每个查询都有一个查询协调器节点。它是接收SQL查询请求的节点。
  • 协调器计划执行查询，从倒数第二个执行节点接收结果，执行任何终的汇总，排序或过滤，然后将结果流回客户端，
  • 考虑到数据是任意划分的，查询计划者将确定并行化的程度，以小化查询的处理时间。
  • 根据需要处理的数据和并行性的范围，计划者/优化者甚至可以选择重新划分合格数据

处理网络延迟
F1的主要数据存储区是Spanner，它是一个远程数据源。F1 SQL还可以访问其访问涉及高度可变的网络延迟的其他远程数据源。
通过在查询生命周期的各个阶段使用批处理和流水线处理，可以减轻与远程数据访问相关的问题（由于网络延迟而引起的问题）。查询运算符还设计为将尽可能多的数据流传输到处理管道的后续阶段。
后...。
自2012年初以来，F1系统一直在管理生产中的所有AdWords广告活动数据。AdWords是一个广泛而多样的生态系统，包括100多个应用程序和1000多个用户，它们共享同一个数据库。该数据库超过100 TB，每秒可处理数十万个请求，并运行SQL查询，每天扫描数十万亿条数据行。即使在计划外停机的情况下，可用性也达到了五个九，与旧的MySQL系统相比，我们的Web应用程序上可观察到的延迟没有增加。

来源 https://zhuanlan.zhihu.com/p/91635202

相关文章