上回书，我们讲到了 Eon 模式下的查询执行，了解到Eon模式依托着强大 Vertica 架构、独树一帜的分片机制，将查询引领上了新纪元（前文回看：云原生数据库系列谈（肆）：分片机制引领查询新纪元）。
那么在数据存储方面，Eon 模式又会有哪些出挑的表现呢？
依靠共享存储来持久化整个群集中的数据和元数据，因此共享存储需要具备下列特性：
持久性：写入成功后，存储子系统中的故障极不可能导致数据丢失。
可用性：即使存储子系统出现故障，读写操作也很有可能成功。
全局可寻址：从任何计算节点都可以使用相同路径读取任何数据。
弹性：容量按需增加，仅受购买力限制。
另外，共享存储还具有读写访问延迟高于本地存储、带来成本消耗、缺少POSIX特性等特点。
这种种特性，决定了要高效存储首先要做到对数据的合理布局。
数据布局之道
在Vertica企业模式下，这些特性能够确保数据布局的合理
- 数据库将数据写入本地磁盘。
- 每个节点都将文件写入单独的名称空间，从而确保节点之间不存在文件名冲突。
- Vertica采用双层目录结构，以免因为目录中文件太多导致文件系统过载。
- Vertica采用全局唯一存储标识符（SID）来识别文件。 如下图所示，SID是节点实例ID（Vertica进程启动时生成的120位随机数）与本地ID（存储对象创建时关联的64位编录OID）的组合。
- 列数据和删除向量使用相同的机制。
- 象使用元数据对象标识符（OID）这样的简单命名机制足以唯一命名文件，以便执行引擎可以根据元数据信息打开文件。
- 存储对象不属于任何特定的节点，因为许多节点都可以订阅相同分片。
需要说明一点的是，如果没有给对象全局唯一的名称，则群集之间的重复副本（可能是双向的）需要保持持久映射并导致复杂度显著增加。
注：Eon模式不支持WOS; 所有修改操作都需要保存到磁盘。
使用WOS，如果节点崩溃，数据可能会丢失！！！(因为在Eon模式下不再有伙伴投影）
分担负担之道
直接在共享存储的数据上执行所有查询将导致较差的性能，并且会使共享存储承受沉重负担。Vertica Eon模式引入缓存来避免从共享存储中读取常用数据
这里的缓存是基于磁盘的，用于缓存来自共享存储的完整数据文件。由于Vertica确保从不修改已提交的存储文件，因此缓存只需处理添加和删除操作，而不会失效。
关键词：缓存逐出
缓存逐出策略是一种简单的最近最少使用（LRU）机制，它假设过去的访问行为可以很好预测未来的需求。 LRU已被证明是一种有效的页面替换算法。
关键词：直写式(Write-through)
缓存是直写式(Write-through)的，因为新添加的文件可能很快会被查询引用。 在加载时，文件被写入缓存，上传到共享存储并发送到订阅相关分片的所有节点。
关键词：节点与分片
当一个节点订阅一个分片时，它会根据对等节点的缓存内容来预热自己的缓存。 节点尽量从同一个子集群中选择对等节点，以确保缓存内容与节点将要面对的工作负载相匹配。
云上访问之道
直接Vertica目前支持三种文件系统：POSIX，HDFS和AWS S3。开放这个API并让用户构建自己的UDFS实现，以在他们选择的共享存储上运行Eon模式，这是未来我们要工作的内容
这里Vertica执行引擎对文件系统的访问是通过能提供有多种内部不同类型实现的抽象文件系统API来完成的。
鉴于Eon模式专注于云，S3是满足共享存储所需特性的一种实用的选择：
- S3是一个对象存储，与POSIX Linux文件系统有几个关键的语义差异。
- 对象不支持全部的POSIX操作（例如重命名，追加）。
- S3没有目录；
- S3的路径通配功能不同。
- S3暴露出的一致性模型也和常规文件系统不同。
- S3需要不同的优化来实现良好的性能。
- 与S3的安全模型集成对于安全部署而言非常关键。
- S3对象是不可变的：将x追加到对象y上是不可能的。 在这种情况下，必须基于y和x的内容创建一个全新的对象，如果原始对象很大，这可能代价会很高。
Vertica观察到S3比使用本地文件系统更容易出故障。因为用户希望他们的查询可以被取消，因此Vertica不能挂起来一直等待S3的响应。
最后，请求需要花钱，所以最小化请求量会降低操作成本。
▼▼▼
下回书，我们来了解一下企业模式下数据库的那些操作行为。
本系列文章摘编自刘定强所著《从无共享MPP列式数据库到弹性的云原生分析平台》