云原生数据库系列谈(伍):VERTICA 的存储之道
数据库将数据写入本地磁盘。
每个节点都将文件写入单独的名称空间,从而确保节点之间不存在文件名冲突。
Vertica采用双层目录结构,以免因为目录中文件太多导致文件系统过载。
Vertica采用全局存储标识符(SID)来识别文件。如下图所示,SID是节点实例ID(Vertica进程启动时生成的120位随机数)与本地ID(存储对象创建时关联的64位编录OID)的组合。
列数据和删除向量使用相同的机制。
象使用元数据对象标识符(OID)这样的简单命名机制足以命名文件,以便执行引擎可以根据元数据信息打开文件。
存储对象不属于任何特定的节点,因为许多节点都可以订阅相同分片。
图:Vertica用于构建全局文件名的存储标识符格式
需要说明一点的是,如果没有给对象全局的名称,则群集之间的重复副本(可能是双向的)需要保持持久映射并导致复杂度显著增加。
注:Eon模式不支持WOS; 所有修改操作都需要保存到磁盘。
使用WOS,如果节点崩溃,数据可能会丢失!!!(因为在Eon模式下不再有伙伴投影)
图:数据加载工作流程。提交之前文件被对等节点缓存并已保存到共享存储
这里的缓存是基于磁盘的,用于缓存来自共享存储的完整数据文件。由于Vertica确保从不修改已提交的存储文件,因此缓存只需处理添加和删除操作,而不会失效。
关键词:缓存逐出
缓存逐出策略是一种简单的近少使用(LRU)机制,它假设过去的访问行为可以很好预测未来的需求。LRU已被证明是一种有效的页面替换算法。
关键词:直写式(Write-through)
缓存是直写式(Write-through)的,因为新添加的文件可能很快会被查询引用。在加载时,文件被写入缓存,上传到共享存储并发送到订阅相关分片的所有节点。
关键词:节点与分片
当一个节点订阅一个分片时,它会根据对等节点的缓存内容来预热自己的缓存。节点尽量从同一个子集群中选择对等节点,以确保缓存内容与节点将要面对的工作负载相匹配。
图:UDFS API示意图
这里Vertica执行引擎对文件系统的访问是通过能提供有多种内部不同类型实现的抽象文件系统API来完成的。
鉴于Eon模式专注于云,S3是满足共享存储所需特性的一种实用的选择:
S3是一个对象存储,与POSIX Linux文件系统有几个关键的语义差异。
对象不支持全部的POSIX操作(例如重命名,追加)。
S3没有目录;
S3的路径通配功能不同。
S3暴露出的一致性模型也和常规文件系统不同。
S3需要不同的优化来实现良好的性能。
与S3的安全模型集成对于安全部署而言非常关键。
S3对象是不可变的:将x追加到对象y上是不可能的。在这种情况下,必须基于y和x的内容创建一个全新的对象,如果原始对象很大,这可能代价会很高。
Vertica观察到S3比使用本地文件系统更容易出故障。因为用户希望他们的查询可以被取消,因此Vertica不能挂起来一直等待S3的响应。
后,请求需要花钱,所以小化请求量会降低操作成本。
来源 https://mp.weixin.qq.com/s/NTnGLCXJHTj59MA5NWfU-Q
相关文章