Google F1 Schema 变更算法

Schema

Schema 是数据库的组织结构，包含 Schema 对象，可以是表、列、数据类型、视图、存储过程、关系、主键、外键等，反映了数据库对象和其相互之间的关系。从 Schema 可以直接定义一个数据库。

Schema 变更

由于所有的 F1 服务器共用一个 KV 存储引擎，但上百台服务器的 Schema 变更却无法在同一时间点进行变更，Schema 的异步变更可能会带来严重的数据错乱。

Schema 变更算法

算法思路

• 规定时间点，在这个时间点之前所有服务器要完成变更操作，如果超时没有完成的话则认为服务器下线停止工作。服务器需要按照规定的时间间隔（短于变更时长）到 KV 存储引擎中查看特殊的键值对来判断自己是否需要改变。
• 设计中间状态，使两两中间状态可兼容，整个变更过程转化为演化过程。

Schema 状态

两个非中间状态：absent、public
两个中间状态：delete-only、write-only

• absent 表示对象完全不存在
• public 表示对象正常工作，可读可写
• delete-only 的 table、column、index 的 k-v 值无法被事务读取，并且
  • table 和 column 仅能被 delete 操作修改。
  • index 仅能被 delete 和 update 操作修改。其中 update 操作能删除相关 index 的 k-v 对但不能创建新的。
• write-only 的 column、index 的 k-v 值能被 insert、delete、update 操作修改，但无法被用户事务读取。
• write-only 的约束对所有新的 insert、delete、update 操作有效，但不保证对所有现存数据有效。

Schema 变更算法细节

添加 Schema 状态转换过程：

• 删除元素的状态过程与添加相反，并且 db reorg 发生在 absent 之前。
• db reorg （数据重组）指在 Schema 最后确认变更之前的一系列操作，保证在 public 或 absent 之前所有旧数据的元素相关整合处理完成。

状态变更流程（以新建索引为例）

• 从 absent 到 delete-only 的状态转换，对于 absent 来说由于索引不存在，添加删除元素相关数据都不会导致索引数据出现变化，对于 delete-only 状态来说只能删除元素相关的数据，但之前并没有元素产生的索引数据没得可删，所以对于两种状态的节点来说都不会发生数据的异常。
• 从 delete-only 到 write-only 的状态转换，delete-only 与 write-only 都能在删除数据时同步删除与索引相关索引数据，并且进入 write-only 状态后写入的索引数据在所有节点都可以删除，不会出现残留不该出现的数据的情况。由于两状态都不对外界事务可见，因此也不会出现完整性异常。
• 当进行 db reorg 操作的时候需要保证没有服务器还处于 delete-only 状态，并且补全与新数据写入时带来的与新索引相关的索引数据缺失。
• 数据重组完成之后的服务器节点就可以上线了。

算法实现

Schema 租约

每个 F1 服务器协定了长达数分钟的 schema lease（租约），到期后再从一个已知的地方重载 Schema 来续约。如果无法续约，则终止服务并等待被重启。

用户的事务被允许跨多个租约，但需要限制写操作只能使用具有有效租约的 Schema 。这是十分必要的，因为在提交的时候，写操作就被转换成 k-v 存储的相关操作。如果一个单独的写操作需要超过2个 lease 来执行，则违反了基本要求（任何时候只有最新2个版本的 Schema 可被使用）。这些可以用 Write fencing（每个独立的写操作可设置deadline，使得操作基于最新或次新的schema）来实现。

优化：

• 使用 Spanner 的原子操作 test-and-set 同时复制 Schema 的标准副本到多个位置。
• 在 F1 服务器上缓存当前 Schema 的 commit 时间戳。当 F1 服务器续约时，先读取标准 Schema 的时间戳，如果时间戳和缓存的相同，则无需重新读取 Schema。
• 因为逾期而被终止并重新提交的写操作会造成资源浪费，所以可以通过尽早续约来减少写失败的可能性。但频繁的续约操作会增加 F1 和 Spanner 的系统负载，因此建议在租期还剩一半的时候进行续约。

数据重组

• 整个数据重组过程不具有原子性。因此，数据重组操作必须可回滚且幂等。
• 重组过程中所有数据必须可用。
• 应尽量避免重复执行用户事务中的数据更改。

数据重组需要用到 MapReduce 框架。每个 map 任务对于其负责的 partition，扫描 Schema 变更开始时的 snapshot，更新每一行以符合新 Schema。在更新每一行的时候判断其在重组开始之后是否被用户事务更新过，如果是的话则不做修改。

总结

关于 Schema 状态（例如 delete-only、write-only），通常理解为当所有可用的服务器上的 Schema 均切换到某一状态后才表示可以开始切换到下一状态。

总体上论文所呈现出来的是一个可行且完善的分布式异步 Schema 变更的解决方案，但这个方案中的很多地方都隐含着一个重要的前提：基于时间戳的操作（涉及乐观锁、重组、事务等）必定需要一套可信的时序机制作为基本保障。财大气粗的 Google 研发出了基于 GPS 和原子时钟的 TrueTime 来控制时间误差，即硬件级解决方案。软件层面上 Cockroachdb 使用的 Hybrid Logic Clock 实现起来非常复杂。所以一种简单可行的方法就是打破 无状态、无全局成员 的限制，用一个节点专门用来提供统一的授时服务。