Google F1 Schema 变更算法

本文主要是介绍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 的状态转换，

这篇关于Google F1 Schema 变更算法的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！