F1参考笔记

本文是对f1这篇在线DDL论文再一次有一点自己的阅读理解，如果您发现文章观点错误，请在评论中不吝赐教。

F1参考笔记

说是参考，是因为之前看了F1的这篇大名鼎鼎的论文《Online, Asynchronous Schema Change in F1》感觉理解的还是不够深入，又学习到了另外两篇博文后自己又悟了一些(日常悟了)，这两篇文章分别是理解Google F1:Schema变更算法和《谷歌F1 Online DDL的关键点》；

关键点总结：

  1. 我们通过控制lease时间，可以保证同一时刻最多只有两个schema，分别是最新版本和次新版本；

    这句话需要理解最多二字，通过变更算法这篇文章中我们知道，只要我们根据实际情况设定了一个确定的lease，那么就可以保证从某一个时刻开始到lease这段时间之后，一定可以保证所有节点全部到达了最新的版本状态，但是这段时间【内】可能会有DML语句过来，此时就可能会有两个版本的schema，但是通过设置lease我们就可以确定同一个时刻最多只有两个版本的schema，为后面多版本schema兼容变更打下基础；

  2. 增加了delete-only状态和write-only状态后，之所以可以在线更新schema是因为：各个相邻schema都是兼容的，互相不嫌弃；

    这里需要着重说明，相互兼容、互补嫌弃指的是对于数据存储的完整性、一致性来说，也就是论文中的3.2 Database consistency一节中的Definition 4的七个小点，这里贴一下部分原文

    1. No column values exist without a containing row and table. For every column key–value pair ⟨kr(C),vr(C)⟩ ∈ d there exists ⟨kr(exists),null⟩ ∈ d and there exists table R ∈ S containing column C.

    2. All rows have all public required column val- ues. For every required public column C in table R ∈ S, if there exists ⟨kr(exists),null⟩ ∈ d, there exists ⟨kr(C),vr(C)⟩ ∈ d.

    3. No index entries exist without a corresponding index in the schema. For every index key–value pair ⟨kr(I),null⟩ ∈ d there exists table R ∈ S containing index I.

    4. All public indexes are complete. If there exists a public index I on R ∈ S, then there exists an index key–value pair ⟨kr(I),null⟩ ∈ d for every row r ∈ R.2

    5. All index entries point to valid rows. Conversely, for every index key–value pair ⟨kr(I),null⟩ ∈ d, there exists a column key–value pair ⟨kr(C),vr(C)⟩ ∈ d for every column C covered by index I.

    6. All public constraints are honored. No key–value pair exists in d that violates a public constraint listed in S, and all key–value pairs that must be present ac- cording to public constraints in S exist in d.

    7. No unknown values. There are no key–value pairs in database representation d except those postulated in Clauses 1 and 3 of this definition.

    需要着重强调：新增了delete-only状态和write-only状态不会影响数据存储的完整性，并不是说对于所有的DML毫无影响，数据完整性大致可以分成两类：不会有多的数据不会有少的数据； 例如不会有发生一个表的某一行被删除掉了但是该行关联的索引却没有删除，不会发生某个表的某行插入时该行关联的索引却没有的情况；

    但是，并不是对所有的DML都没有影响，例如write-only阶段执行完并且db reorg之后，就可以将schema变成public状态了，此时集群会存在有的F1节点转换成了public状态，有的还是维持在write-only状态；

    举例以新增一个索引index E来说，那么对于select来说就可能会存在有的节点可以读出index E，但是某些节点读不出index E；这需要应用层自己去做处理，因为修改schema的时候应用层肯定要考虑兼容。

    下面可以一一进行对比：

    • absent和delete-only：如果有删除操作那么二者都不包含了，相互兼容；如果有新增操作二者都没有办法新增，同样互相兼容；
    • delete-only和write-only：如果有删除操作那么二者都可以进行删除，相互兼容；如果有新增操作，虽然write-only会把数据写入，但是仍然没有办法进行读取，因此还是兼容的；
    • write-only和public：需要说明的是在原文中write-only到public时还有一个database reorganization，但是你可以理解成时write-only版本变更到public版本时做的一种自发的数据补充操作，并且在database reorganization完成后才会开始public状态切换，此时全部的数据已经补充完整了，只是针对SELECT读不出来，所以数据读写都是兼容的。