Vertica 节点与集群规模规划指南¶
编译：JiangChong
原文：Recommendations for Sizing Vertica Nodes and Clusters（2020）
📝 文章说明：本文基于 Vertica 官方 KB 原文翻译整理。原文发布于 2020 年，仅讨论了 Enterprise 模式下的纯硬件选型和节点数量估算，未涉及 Eon 模式在存算分离架构下的 分片（Shard）、子集群（Subcluster）和 Depot 缓存 的规划方法论。译者根据 Vertica v26.2 官方文档和 vault 已有技术笔记，补充了 Eon 模式「3+1 规划模型」（分片 S / 子集群 SC / Depot D + 节点 N）、Eon 扩缩容机制（REBALANCE_SHARDS / RESHARD_DATABASE / ECS）、以及 Enterprise vs Eon 规划方法论对比表和分步决策框架。新增内容位于「Eon 模式集群规模规划方法论」章节。
概述¶
本文是 Vertica 节点的硬件规划指南，在官方 2020 年版基础上，结合 2026 年硬件市场现状更新了 CPU、内存、存储和网络的推荐配置。同时补充了 Eon 模式下的分片-节点-子集群-Depot 四位一体规划方法论，涵盖：分片数选择与节点并行度、子集群隔离策略（主/次级、ETL/查询分离）、Depot 缓存容量计算、以及存算分离架构下的弹性扩缩容与 Enterprise 模式纯节点规划的对比决策框架。
2020 → 2026：硬件环境的关键变化¶
| 维度 | 2020 年（原文） | 2026 年（现状） |
|---|---|---|
| CPU | Intel Cascade Lake（14nm）；单路 8–12 核 | Intel Granite Rapids / AMD EPYC Turin（5nm/3nm）；单路 32–64 核是主流；ARM64 正式支持 |
| 内存 | DDR4-2133/2666 | DDR5-4800/5600，带宽翻倍 |
| 存储 | SAS 10K/15K HDD 为主；NVMe 价格高 | NVMe PCIe Gen4/Gen5 成本大幅下降，已成默认推荐；HDD 仅用于冷数据成本优化 |
| 网络 | 10GbE | 10GbE 仍为最低要求，25GbE/100GbE 逐步普及 |
| Vertica | 9.x/10.x，企业模式为主 | 24.x/25.x/26.x；Eon 模式成熟；K8s 部署、S3 公共存储 |
Vertica 最优硬件配置（2026 修订）¶
| 组件 | 推荐配置 |
|---|---|
| 处理器 | x86_64：Intel Xeon 6th Gen（Granite Rapids）或 AMD EPYC 9005（Turin），单路 32–48 核，主频 ≥ 2.6 GHz ARM64：AWS Graviton4 / Ampere Altra Max（Vertica 24.4.x 起官方支持），适用 Eon 云端场景 超大集群（> 100 TB 压缩数据）可考虑双路 CPU 以获得更多核心和内存通道 务必在 BIOS 中禁用 C-State 和频率调节节能功能 |
| 内存 | 每物理核心 8–12 GB（按物理核而非超线程逻辑核算） DDR5-4800 起步，推荐 DDR5-5600 所有内存通道需均匀填充以避免降速 256 GB 起步，大集群 512 GB–1 TB |
| 存储 | 首选 NVMe SSD（PCIe Gen4/Gen5），顺序读 ≥ 3000 MB/s 每核心最低 60–80 MB/s 读写吞吐， vioperf 实测验证Enterprise Mode：每节点 3–10 TB NVMe 构建 RAID 10 Eon Mode depot：每节点 2–8 TB NVMe（不建议额外配置 RAID，多盘分别挂载即可） HDD 仅在冷数据归档或超大规模低成本场景下作为成本优化选项（仍需 ≥ 20 块 10K+ 盘组 RAID 10） RAID 控制器缓存比建议 10/90（读/写） |
| 网络 | 10GbE 双端口 bonding 为最低要求 大集群或高吞吐场景推荐 25GbE 私网（集群心跳 + 数据交换）与公网（客户端接入）分离 LACP bonding 实现冗余和带宽叠加 |
关于 NVMe vs HDD 的成本选择： 原文（2020）认为 HDD 阵列「足够满足需求、无需 SSD」。这在 2020 年是合理的——当时 NVMe 价格是 HDD 的 5–10 倍。到 2026 年，NVMe SSD 每 TB 价格已大幅下降，而 Vertica 是 I/O 密集型分析数据库，CPU 等磁盘的时间占比直接影响查询延迟。对于绝大多数新部署，NVMe 的性价比已全面超越 HDD。 HDD 仅建议用于数百 TB 以上冷数据归档且对查询延迟不敏感的场景。
集群规模规划¶
规划集群规模时需考虑以下三个核心因素：
1. 数据量（压缩比）¶
先估算原始数据总量，再乘以压缩比。大多数场景下 2:1 到 3:1 的压缩比 是合理的起点（Vertica 的列存编码压缩在实际业务中常能超过 3:1）。
计算压缩比的方法： - 使用历史已知的压缩比数据 - 在现有系统安装 Vertica，运行 Database Designer（DBD）获取列级压缩估算 - 加载约 10% 的代表性数据，通过审计统计投影存储的已用字节数
2. 数据增长¶
- 数据摄入速率（每天加载的数据量，GB/天）
- 保留策略（数据计划保存的天数）
3. 工作负载¶
- 并发度：同时运行的查询数。并发越高，所需内存和 CPU 核心越多
- 查询复杂度：简单聚合 vs 复杂多表 JOIN + 窗口函数
- 数据加载频率：微批（分钟级）vs 批量（小时/天级）
- 资源池管理：通过
RESOURCE_POOL控制优先级和并发上限
推荐服务器配置（2026 修订版）¶
高可用部署至少需要 3 个节点（K-safety=1）。以下配置基于原始数据量并假设 2:1 压缩比；如果你的压缩比更好，所需节点数可相应减少。
对于 Enterprise Mode（数据本地存储）：
| 原始数据量 | 节点数 | 每节点配置 |
|---|---|---|
| < 5 TB | 3 | 单路 32–48 核 CPU（≥ 2.6 GHz） 128–256 GB DDR5 内存 3–5 TB NVMe SSD（RAID 10） |
| 5–10 TB | 3–4 | 单路 32–48 核 CPU（≥ 2.6 GHz） 256 GB DDR5 内存 3–5 TB NVMe SSD（RAID 10） |
| 10–50 TB | 4–8 | 单路 32–64 核 CPU（≥ 2.9 GHz） 256–512 GB DDR5 内存 5–10 TB NVMe SSD（RAID 10） |
| 50 TB–1 PB | 8–100 | 单路/双路 32–64 核 CPU（≥ 2.9 GHz） 512 GB–1 TB DDR5 内存 10–25 TB NVMe SSD（RAID 10） |
| > 1 PB | 咨询 Vertica | 同上基础配置，但务必联系 Vertica 售前获取精确规划；部署前将 BOM 提交 Vertica 技术代表审核 |
对于 Eon Mode（数据在共享存储，节点本地仅做 depot 缓存）：
| 原始数据量 | 节点数 | 每节点配置 |
|---|---|---|
| < 10 TB | 3–4 | 单路 32–48 核 CPU（≥ 2.6 GHz） 128–256 GB DDR5 2–4 TB NVMe SSD（depot，不建议额外配置 RAID） |
| 10–100 TB | 4–12 | 单路 32–64 核 CPU（≥ 2.6 GHz） 256–512 GB DDR5 2–6 TB NVMe SSD（depot） |
| 100 TB–5 PB | 12–100 | 单路/双路 32–64 核 CPU 512 GB DDR5 4–8 TB NVMe SSD（depot） |
Eon Mode 公共存储带宽要求： 每个节点需 ≥ 200 MB/s 读写吞吐到共享存储（S3/MinIO/HDFS），建议达到 500 MB/s。例如 20 节点集群至少需要 20 × 200 = 4 GB/s 总带宽。
关于 Eon 配置表的说明： 上表按原始数据量给出节点数参考，便于快速选型。但 Depot 容量的精确计算应按压缩后工作集而非原始数据量——详见下文「Eon 模式集群规模规划方法论 → Depot 缓存容量规划」。
注意： 以上配置为通用推荐。Enterprise 模式下应留出 20–30% 余量（rebalance 代价高）；Eon 模式下可从最小值起步、按需弹性扩展。购买生产集群硬件前，务必将 BOM 交由 Vertica 技术代表审核。
云部署 vs 裸金属¶
- 裸金属：I/O 一致性最佳，无虚拟化开销，适合极致性能场景
- 云虚拟机：弹性伸缩是核心优势，Eon Mode 天然适配。同一子集群内所有 VM 必须使用相同的实例类型和硬件代数，避免异构性能抖动；不同子集群可按工作负载选配不同实例类型
- Kubernetes（Eon Mode）：Vertica 24.1.x 起支持 K8s 部署，适合云原生技术栈
Eon 模式集群规模规划方法论¶
本章为补充内容。原文基于 Enterprise 模式，集群规模规划的核心是「数据量 → 节点数 → 每节点硬件配置」。但在 Eon 模式下，存算分离架构要求你将规划维度从 Enterprise 的「节点」单维度，拓展为 分片（S）+ 子集群（SC）+ Depot（D）+ 节点（N） 四位一体规划。
本章方法论的 vault 来源：
- Vertica Eon 模式中分片、节点和 Depot 选择的最佳实践 — S/N/D 核心选择规则
- Vertica 26.2.x Eon Mode 文档 § Configuring Your Vertica Cluster for Eon Mode
- K-Safety 最佳实践 — Eon 分片订阅容错机制
- Vertica 集群 Rebalance 完全指南 — REBALANCE_SHARDS / RESHARD_DATABASE / ECS
规划维度对比：Enterprise 单轴 vs Eon 多轴¶
Enterprise 模式的规划逻辑是线性的：数据量决定节点数，节点数决定每节点硬件。但在 Eon 模式下，数据存储共享意味着节点数不再直接决定数据分布——取而代之的是分片（Shard）和子集群（Subcluster）两个核心抽象。
| 规划维度 | Enterprise 模式 | Eon 模式 |
|---|---|---|
| 数据分布 | 投影按节点数分段存储（SEGMENTED BY HASH） | 分片决定数据分割粒度（Shard Count），分片 ≠ 节点 |
| 并行度上限 | 节点数（每节点持有一部分数据） | 分片数（每个查询最多 S 个分片并发执行） |
| 扩缩容数据迁移 | REBALANCE_CLUSTER() 重分布数据，耗时数小时到数十小时 |
REBALANCE_SHARDS() 调整分片订阅关系，分钟级完成，不迁移数据 |
| 弹性伸缩 | 受限于数据迁移成本，实操中极少频繁伸缩 | 子集群按需启停；ECS 弹性压缩伸缩，计算资源弹性是原生能力 |
| 容量规划 | 节点本地磁盘 = 数据容量 | 节点 Depot = 热数据缓存；总容量由公共存储决定 |
| 工作负载隔离 | 资源池（Resource Pool）仅作 SQL 级别控制 | 资源池 + 子集群（物理隔离计算节点），可设置子集群级资源池覆盖 |
| 容错机制 | Buddy Projection → 节点依赖环 | 分片订阅（Shard Subscription）+ Quorum 保障，K-safety = 1 时至少需 3 个主节点 |
| 存储规划 | 每节点 RAID 10，I/O 并发由磁盘数决定 | 每节点 Depot 用 ext4 直接挂载（官方不建议额外配置 RAID/LVM）；应尽量将工作集完整缓存到本地以最小化公共存储访问 |
RAID/LVM 不建议用于 Depot：Vertica Eon 模式中分片、节点和 Depot 选择的最佳实践 + Vertica KB: Best Practices for Eon Mode
Eon 规划的「3+1」模型¶
在 Eon 模式下，集群规划需要同时考虑四个可变维度（3+1 = S/SC/D + N）：
┌──────────────────────────────────┐
│ 公共存储（S3/HDFS/MinIO） │
│ 全量数据，决定总存储成本与带宽规划 │
└──────────┬───────────────────────┘
│ 每个节点通过 Depot 缓存热数据
┌───────────────┼───────────────────────┐
│ │ │
┌───▼───┐ ┌─────▼─────┐ ┌──────▼──────┐
│ 分片 S │────▶│ 子集群 SC │◀─────────│ Depot D │
│Shard │ │Subcluster │ │ 本地缓存 │
│ 数据 │ │ 计算组织 │ │ 按工作集计 │
│ 并行度 │ │ 隔离+弹性 │ │ 每节点≥2TB │
└───┬───┘ └─────┬─────┘ └──────┬──────┘
│ │ │
└───────────────┼───────────────────────┘
│
┌─────▼─────┐
│ 节点 N │
│ CPU/内存 │
│ 计算资源 │
└───────────┘
四个维度的关系：
- S（分片数）决定并行度上限：任何查询最多在 S 个分片上并行执行。N ≥ S 且整除时全节点参与（ECS 将分片工作分担到多节点）；N < S 时部分节点承载多个分片
- SC（子集群）决定计算组织形式：主集群做 DDL/ETL，次级集群做查询；同一 SC 内节点数应为分片数的约数或倍数
- D（Depot）决定热数据命中率：Depot 不够大 → 频繁从公共存储拉取 → 查询延迟上升
- N（节点数）决定并发吞吐量：N > S 时 ECS 提升并发（同分片多节点分担），但单查询延迟不降；N = S 时单查询性能最优
1. 分片（Shard）规划¶
分片:节点比例¶
根据 Vertica Eon 模式中分片、节点和 Depot 选择的最佳实践 及 Vertica 26.x 官方文档：
| 规则 | 约束 | 说明 |
|---|---|---|
| 最佳性能 | S = N | 每个节点恰好订阅 1 个分片，全节点并行查询 |
| 推荐上限 | S ≤ 2×N | 官方推荐分片数不超过节点数的 2 倍 |
| 绝对上限 | S ≤ 3×N | 硬上限，超过会显著增加 catalog 开销和分片调度复杂度 |
| 整除约束 | N % S = 0 或 S % N = 0 | 避免分片分布不均导致热点节点 |
实践经验¶
- 通常选择 6 到 16 之间的分片数量
- 选择具有更多约数的分片数（如 6、8、12、24），便于未来灵活扩展
- 从 Enterprise 迁移到 Eon 时，分片数默认 = 原 Enterprise 节点数
- 分片数可在创建后通过
RESHARD_DATABASE()在线调整（Vertica 12.0+）
-- 在线调整分片数（获取全局 catalog 锁，建议低峰期执行）
SELECT RESHARD_DATABASE(12);
-- 加速存储容器重新对齐
SELECT DO_TM_TASK('RESHARDMERGEOUT');
命名空间级分片¶
较新版本支持多个命名空间各自使用不同分片数：
- 大表 / 复杂分析工作负载 → 高分数（如 12）
- 小表 / 简单仪表板查询 → 低分数（如 3~6）
- 将表大小与分片数对齐可最小化 catalog 开销
2. 子集群（Subcluster）规划¶
子集群是 Eon 模式中最核心的计算组织形式。详见 Vertica 26.x 官方文档 Improving query throughput using subclusters。
主子集群 vs 次级子集群¶
| 类型 | 定位 | 典型用途 | 注意事项 |
|---|---|---|---|
| 主子集群（Primary） | 常驻节点，永远在线 | 数据加载、DDL、日常维护 | 至少 3 个节点（K-safety=1）；不建议频繁启停 |
| 次级子集群（Secondary） | 按需启停，弹性伸缩 | 查询工作负载、报表、分析 | 可按天/小时调度启停，节省计算成本；同子集群内节点须同构，但不同子集群可根据子集群具体的业务场景差异化配置 |
子集群规划模式¶
模式 A：单子集群（小规模 / 简单场景）
模式 B：ETL + 查询分离（最常见）
主子集群（6 节点）── 仅用于数据加载和 DDL
次级子集群（6 节点）── 仅用于用户查询和报表
次级子集群（6 节点）── 高峰弹性查询集群（按需启停）
通过连接负载均衡或路由策略将不同 workload 定向到对应子集群
模式 C：多工作负载隔离（大规模 / 多部门）
主子集群（6 节点）── ETL + DDL
次级子集群 A（6 节点）── 业务部门 A 查询
次级子集群 B（4 节点）── 业务部门 B 查询
次级子集群 C（4 节点）── 数据科学 / ML 训练
次级子集群 D（按需）── 月末报表高峰弹性集群
每个次级子集群可配置独立的资源池覆盖（Subcluster Resource Pool Overrides）
子集群节点数与分片数的整除约束¶
同一子集群内节点数应能被分片数整除或分片数能被节点数整除，确保分片均匀分配。例如 S=6 时：
| 节点数 | 整除关系 | 每节点分片数 | 是否均匀 |
|---|---|---|---|
| 3 | 6 % 3 = 0 ✅ | 2 | 均匀 |
| 6 | 6 % 6 = 0 ✅ | 1 | 均匀（最优） |
| 12 | 12 % 6 = 0 ✅ | ECS 分担 | 均匀 |
| 4 | 6 % 4 ≠ 0 ❌ | 1.5 | 不均匀，热点 |
| 5 | 6 % 5 ≠ 0 ❌ | 1.2 | 不均匀，热点 |
3. Depot 缓存容量规划¶
Depot 是每个节点上的 LRU 缓存，存储从公共存储拉取的热数据。核心目标是尽量将工作集完整缓存到本地 Depot，让查询命中本地 NVMe 而非公共存储——缓存命中率直接决定查询性能。它是 Eon 模式查询性能的关键。
Depot 大小计算公式¶
来源：Vertica v26.2 官方文档 + Vertica Eon 模式中分片、节点和 Depot 选择的最佳实践
两步计算法：
Step ② 的 × 1.67 系数 来源于 Depot 占本地存储 60%：每节点需额外 40% 用于 catalog + 临时数据（Spill），因此本地存储总量 = Depot 需求 / 60%。
计算示例（按官方文档公式）：
| 场景 | 压缩工作集 | 子集群节点 | ① 每节点 Depot | ② 每节点本地存储 |
|---|---|---|---|---|
| 小型 | 12 TB | 3 | 4.0 TB | 6.7 TB |
| 中型 | 24 TB | 6 | 4.0 TB | 6.7 TB |
| 大型 | 48 TB | 12 | 4.0 TB | 6.7 TB |
| 超大 | 100 TB | 24 | 4.2 TB | 7.0 TB |
每节点本地存储 ≥ 2 TB（官方最低要求）。上表 Depot = 工作集/节点数，本地存储 = Depot × 1.67，均已四舍五入。
以分片粒度估算 Depot（针对 N > S 的场景）：
实际中一个节点通常至少缓存 2 个分片以留余量。例如总压缩数据 1.2 TB、S=6 → 每分片 200 GB，每节点缓存 2 个分片 → Depot ≈ 400 GB。如果 N > S（ECS 场景），每节点订阅的分片份额更小，但仍建议按 1~2 个完整分片估算 Depot，避免频繁从公共存储拉取。
Depot 关键约束¶
- 规划目标：工作集完整缓存。Depot 应足够大以容纳全量热数据，避免查询时频繁从公共存储拉取。缓存未命中（Depot miss）导致查询延迟大幅上升
- 每节点本地存储 ≥ 2 TB（官方最低要求），其中 ≈ 60% 分配给 Depot
- 单次加载事务的数据量 不能超过子集群 Depot 总容量（否则加载失败）。如需加载超大事务，设置
UseDepotForWrites = 0直接写公共存储（性能会下降） - Depot 盘官方不建议额外配置 RAID/LVM（Depot 只是缓存，数据持久化在公共存储，RAID 冗余和校验开销对缓存卷不必要）；直接用 ext4 挂载即可。当然如果硬件 RAID 已存在，也可以继续使用，不影响功能
- 不宜频繁修改 Depot 大小（虽有
ALTER_LOCATION_SIZE()功能） - 监控 Depot 活动：
vs_depot_lru、dc_depot_evictions、dc_depot_fetches、dc_depot_uploads
公共存储带宽要求¶
每个节点需 ≥ 200 MB/s 读写吞吐到公共存储，建议达到 500 MB/s。计算公式：
例如 12 节点集群：最低 12 × 200 = 2.4 GB/s，推荐 12 × 500 = 6 GB/s。带宽不足会导致 Depot 填充速度跟不上查询需求，频繁出现缓存未命中。
关于带宽实测方法，详见 depot_uploads/depot_fetches 分钟级峰值 SQL。
4. 扩缩容规划：Enterprise vs Eon¶
这是 Enterprise 与 Eon 在规模规划上最重要的分水岭：
| 操作 | Enterprise 模式 | Eon 模式 |
|---|---|---|
| 增加节点 | REBALANCE_CLUSTER() — 数据重分布到新节点，CPU/磁盘/网络密集，耗时数小时到数十小时 |
REBALANCE_SHARDS() — 仅调整分片订阅关系，分钟级完成，不迁移数据 |
| 减少节点 | 受 K-safety 约束，需 REBALANCE_CLUSTER() 迁移数据 |
REBALANCE_SHARDS() 或直接 DROP 次级子集群节点（不持有唯一分片即可） |
| 弹性伸缩 | 几乎不可行（数据迁移代价过高） | 原生支持：子集群按需启停、ECS 弹性压缩伸缩 |
| 迁移到 Eon | — | MIGRATE_ENTERPRISE_TO_EON() 后分片数 = 原节点数，可用 RESHARD_DATABASE() 优化 |
| 重新分片 | — | RESHARD_DATABASE() 在线调整分片数（S），获取全局 catalog 锁 |
Enterprise 模式下每增加一个节点都是一次重大变更（数据重分布），因此在 Enterprise 规划中必须为未来增长预留 20-30% 余量，初期节点数是「过度配置」的。但在 Eon 模式下，你可以从最小值开始，按需增加子集群或节点——这种灵活性是 Eon 模式在规模规划中最核心的优势。
5. Enterprise vs Eon 规划方法论对比¶
| 规划步骤 | Enterprise 模式 | Eon 模式 |
|---|---|---|
| 1. 估算压缩数据量 | 原始数据 / 压缩比（2:1~3:1） | 同左（数据总量由公共存储决定） |
| 2. 确定工作数据集 | 全部数据 = 工作数据（全部本地存储） | 明确「热数据（工作集）」vs「冷数据」边界 |
| 3. 选择并行度 | 节点数 = 并行度 | 先选分片数 S（并行度），再选节点数 N |
| 4. 确定节点数 | 数据量 / 每节点容量 | 基于节点:分片比例（S ≥ N 或 N 为 S 的约数/倍数） |
| 5. 确定存储大小 | 每节点 RAID 10 容量 = 数据量 / 节点数 × (1+K) | 每节点 Depot = 工作集 / 节点数；本地存储 = Depot × 1.67 |
| 6. 工作负载隔离 | 资源池（SQL 级别） | 子集群（计算物理隔离）+ 资源池覆盖 |
| 7. 增长余量 | 必须预留 20-30%（rebalance 代价高） | 可从最小值开始（弹性扩缩代价低） |
| 8. 容错规划 | Buddy Projection + K-safety 节点数 | 分片订阅 + Quorum + 可选双主子集群 |
| 9. 网络规划 | 集群内东西向流量（数据交换） | 节点 ↔ 公共存储南北向流量（Depot ↔ S3）为主 |
6. 分步决策框架¶
Enterprise 模式¶
原始数据量 → 压缩比估算 → 压缩数据总量
↓
每节点容量（RAID 10，NVMe 3-25 TB 按规模）→ 节点数 = 总量/每节点容量
↓
CPU/内存（每核 8-12 GB）→ 预留 20-30% 增长余量（rebalance 代价高）
↓
K-safety ≥ 1？→ 节点数 ≥ 3 → 网络 ≥ 10GbE 双口 bond
Eon 模式¶
原始数据量 → 确定热数据工作集大小（最近 N 天/月的数据）
↓
① 选分片数 S：6~16 之间，选有更多约数的值（6/8/12），S 即为查询并行度上限
↓
② 定子集群模式：单子集群？ETL+查询分离？多部门隔离？
├── 主子集群：N0 节点（常驻，N0 ≥ 3），处理 DDL + 数据加载
└── 次级子集群：N1, N2, ... 节点（按需启停），处理查询工作负载
↓
③ 每子集群内 N 与 S 需整除：N % S = 0 或 S % N = 0
↓
④ 每节点 Depot = 工作集 / 节点数；本地存储 = Depot × 1.67（≥ 2 TB）
↓
⑤ 公共存储带宽 = 节点数 × 200-500 MB/s
↓
⑥ K-safety=1 + 主子集群 3+ 节点 → 弹性扩缩通过添加次级子集群或 ECS 实现
扩展阅读¶
- Vertica 数据库硬件配置指南 — Vertica Hardware Guide（含 BIOS、Linux I/O 调优、网络配置详解）
- Vertica RAID 存储方案 — RAID 选型对比
- Vertica Eon 模式中分片、节点和 Depot 选择的最佳实践 — Eon S/N/D 核心选择规则与版本更新
- K-Safety 最佳实践 — Eon 分片订阅容错与双主子集群
- Vertica 集群 Rebalance 完全指南 — Enterprise REBALANCE_CLUSTER vs Eon REBALANCE_SHARDS / RESHARD_DATABASE
- 最新 Vertica 文档