云原生数据库系列谈（陆）：为您盘点Eon模式下的那些神操作
在此前的系列文章中，我们领略了Vertica 的核心架构，了解了Eon模式上的分片、查询和存储机制……
而具体到操作方面，Eon模式还改进了数据库操作的大多数核心组件，从而可以有比企业模式更好的操作行为。
首先，我们就来讲一讲大家颇为关心的节点宕掉与复原的问题。
Vertica Eon 模式对企业模式中的元组移动服务进行了一些修改。此模式下禁用了写优化存储（WOS），所以它不执行移出操作。然而，随着ROS容器数量的增长，合并操作对保持良好性能来说仍然必不可少。
多个节点订阅相同的分段型分片可提高可用性。当节点发生故障时，其他节点无需经过修复操作就可以立即为其负责的分片服务。与企业模式依赖于「伙伴投影」机制不同，Eon模式的全局查询计划在节点宕掉时不会变化，只是由不同节点提供底层数据而已。
关于这一点，我们将在下一篇文章中讲解「节点故障时的性能」的时候，另行具体讲解。
当节点重新加入群集时，它必须重新订阅它以前订阅的那些分片。重新订阅的资源开销密集程度要低于订阅：
节点可以获取增量分片元数据，并且温的缓存要预热只需要传输少量的文件
当重新订阅完成后，节点再次参与查询处理和客户端请求
相比之下，Vertica 企业模式和Eon模式在这上面是有些许区别的，我们不妨来比较一下二者的区别：
企业模式：
企业模式要求修复每个表和投影，这需要在表上加锁来完成。由于企业模式下节点之间副本的存储布局并不相同，因此数据必须在逻辑上传输。
Eon 模式：
节点通过文件物理复制来预热重新订阅节点的缓存。
在差的情况下，该模式下节点复原时间与缓存大小成正比，而企业模式则是与节点上的整个数据集大小成正比。
Vertica Eon 模式对企业模式中的元组移动服务进行了一些修改。此模式下禁用了写优化存储（WOS），所以它不执行移出操作。然而，随着ROS容器数量的增长，合并操作对保持良好性能来说仍然必不可少。
企业模式：
每个节点独立运行合并操作，伙伴投影的复制数据将由多个节点来冗余完成。
Eon 模式：
其中一个订阅者被视为分片的合并协调员来负责选择合并作业的内容。只设置单个协调员是为了确保冲突的合并作业不会被同时执行。
如果分片的合并协调员发生故障，则集群会运行一个事务来选举新的协调员，同时注意保持工作负载均衡。
合并协调员可以自己运行合并作业，也可以将作业分发给其他订阅者，以使合并操作处理能力可以随群集规模线性扩展。
合并作业完成提交时会通知其他订阅者合并操作的结果。协调员也可以分配给特定的子集群，以隔离数据精简工作与其他工作负载。
以前，在Vertica表上添加列是一种复杂的操作，如果这种方式发生在Eon模式下会进一步复杂化。
表元数据更改通常是单次处理事务，它采用重量级的元数据锁来保持一致性，并通过尽可能快地完成来进行性能补偿。
添加列操作需要花时间创建大量数据文件来为所有已经存在的ROS容器填充列值。
企业模式：
添加列操作会先创建文件和不完整的存储元数据。然后再使用元数据锁修改表，并在提交期间将之前准备好的存储元数据附加到表中。
Eon 模式：
Eon模式使用乐观并发控制来推测性地修改表元数据。随后的文件生成操作可以生成附加到表的完整存储元数据，因为新列已经存在。
在提交期间，位于事务写入集合中的每个对象都需要通过验证，以确保没有发生并发修改。
由于Eon模式新增列操作的性能优异，它已经被应用到Vertica新版本的企业模式中。
节点到分片的映射可以快速调整，因为所有数据都存储在共享存储中，而不是直接存储在节点本地。
分片：通过调整订阅将分片的一个子集分配给新节点，可以轻松地将节点添加到系统中，当然可能还包括为了维持平衡顺带要移除其他节点对某些分片的订阅。
查询：可以立即使用新节点，因为不再需要对所有记录进行代价高昂的重新分布。填充缓存需要的时间只与活动工作数据集大小而不是节点负责的全部数据集大小成正比
删除节点：同样变得非常简单，只要确保该节点提供的任何分片都能被其他一个节点提供即可
由于文件从不修改，所以何时删除不再需要的文件是个比较关键的决定。目标是永不删除仍在使用的文件，但终会删除不再需要的所有文件。
企业模式：
Vertica会维护每个文件的引用计数，在计数为零时会考虑删除文件。该计数器会同时跟踪编录引用（如表中的存储容器）以及正在运行的查询的引用。
Eon 模式：
文件不再属于特定节点，因此本地引用计数不足以用来决策。由于有大量的文件且经常变化，在群集范围维护准确的参考计数成本比较高。。
由于采用廉价的共享存储，因此Eon模式可以提供廉价、回收效率略低的算法。
节点只有在所订阅的分片有存储并且通过节点投票的情况下才能删除文件。当引用计数为零时，Eon模式数据库可能需要保留该文件[注]。
需要注意的是：如果负责处理共享存储文件的节点在操作过程中崩溃，那么共享存储上的文件可能会发生泄漏。例如，如果节点在创建文件后、完成通知其他节点前崩溃，这些新创建的文件就可能会泄漏。
为了处理并发创建的文件，操作会忽略带有包含任何运行节点实例标识的存储标识（SID）的存储。尽管删除泄露文件代价较高，但这种操作并不常见，它一般在节点崩溃时被手动运行。
原因一：该文件的在别的节点上的查询引用计数可能不为零，因为并非所有查询都会在全部节点上运行。当本地引用计数为零时，可以立即从节点的缓存中删除该文件。
当群集中小查询版本超过编录引用计数达到零的版本时，节点知道群集上的所有查询都不再引用该文件，就可以安全地删除文件了。文件删除时延迟一定段时间也是一种简单的机制，只要查询执行时间比延时短时就可以避免问题。
原因二：包含存储删除的编录事务可能尚未被保存到共享存储。回想一下，事务提交写入本地磁盘随后再异步上传到共享存储，所以如果丢失所有节点本地磁盘会导致事务回滚。当截断版本超过删除数据的版本时，就可以删除文件。
来源 https://mp.weixin.qq.com/s/v3uFj7mlWI-1Qz1CxiWttQ
相关文章