Vertica 新手入门 — 从核心概念到第一条 SQL

作者：JiangChong | 撰写时间：2026年06月

适用场景：你是第一次接触 Vertica，想用最短时间理解它是什么、怎么工作、怎么上手操作。

读完本文你将能够：

• 用三句话向同事解释 Vertica 是什么
• 理解 projection、segmentation、ROS/WOS、epoch、K-Safety 这些核心概念的大致含义
• 在 Vertica 中建表、加载数据、执行查询、阅读执行计划
• 知道日常运维的 10 个常用命令

理解全文脉络：前两节讲「是什么」和「怎么工作的」（建概念直觉），第三节是动手实操（打开 vsql 跟着敲），第四、五节是速查和下一步指引。如果你已经有 Vertica 环境，可以直接跳到第三节开始操作。

---

1. Vertica 是什么

1.1 起源：从 MIT 实验室到全球部署

Vertica 的故事要从一个人和一篇文章讲起。

Michael Stonebraker（迈克尔·斯通布雷克）是数据库领域最具影响力的人物之一。2014 年，他因「对现代数据库系统底层概念与实践做出的基础性贡献」获得图灵奖——计算机科学的最高荣誉。他的职业生涯跨越近半个世纪，几乎每一步都改变了数据库行业的走向：

年代	项目	影响
1970s	Ingres	最早的关系型数据库之一，奠定了 SQL 查询优化的理论基础
1980s	Postgres	Ingres 的后继项目，引入对象关系模型，后来演变为今天的 PostgreSQL
2000s	C-Store	MIT 列存数据库研究项目，Vertica 的技术前身
2010s	H-Store / VoltDB	内存 OLTP 数据库，探索完全不同的设计方向

Stonebraker 的学术理念是：没有一种数据库架构能同时做好 OLTP 和 OLAP。 与其做一个「万能但平庸」的系统，不如为分析场景从零设计一套全新架构。

2005 年，Stonebraker 与 Andrew Palmer 基于 C-Store 的研究成果共同创立了 Vertica 公司，将这些学术理念产品化。C-Store 的核心洞察是：

• 行存数据库（MySQL、PG 等）物理上把一行数据紧挨着存储，适合「找到用户 123 的全部信息」这类 OLTP 查询
• 但分析查询通常只需要少数几列（如「过去一年每个地区的销售额总和」），行存会读取大量无关列，IO 浪费严重
• 把数据按列存储（同一列的所有值物理上放在一起），查询只读需要的列，IO 大幅下降，而且同列数据高度相似→压缩率极高

这就是 Vertica 的雏形。

2011 年 Vertica 被惠普（HP）收购，2017 年随 HPE 软件部门并入 Micro Focus，2023 年 Micro Focus 被 OpenText 收购，2026 年 Rocket Software 从 OpenText 手中收购 Vertica。二十年间，Vertica 从学术原型成长为成熟的 MPP 分析数据库，Uber、Twitter、Philips 等数千家企业用它处理 PB 级数据分析。

名字由来：Vertica 取自 "vertical"（纵向），对应其列存（columnar）架构——数据「竖着存」。

1.2 一句话定义

Vertica 是一个 MPP 列存分析型数据库。 拆开来看：

• MPP（大规模并行处理）：一台机器算不过来，分给多台一起算。你有 10 亿行数据，Vertica 把它们分散到 3 台服务器上，每台算自己的那一份，最后汇总结果。
• 列存：数据按列存储而非按行。传统数据库（如 MySQL）一行数据紧挨着存；Vertica 把同一列的所有值存在一起。这样做的好处是压缩率高、查询时只读需要的列。
• 分析型（OLAP）：为复杂的聚合查询优化，不适合频繁的小事务操作（OLTP）。

一句话对比：MySQL 是行存 OLTP，适合频繁增删改查单条记录；Vertica 是列存 OLAP，适合对上亿行数据做分组聚合、多表关联分析。

什么时候适合用 Vertica：

• 数据量达到 TB 级别，单机数据库扛不住
• 查询以聚合分析为主（SUM、COUNT、GROUP BY、多表 JOIN）
• 数据以批量加载为主，很少逐行更新或删除

什么时候不适合：

• 你的主要操作是每秒几千次的小事务（这是 MySQL/PG 的强项）
• 数据量只有几百 MB（没必要上 MPP）

来源：Vertica 26.2 文档 Architecture 章节

---

2. 核心概念速览

每个概念遵循「解决什么问题 → 是什么 → 比喻 → 日常意味着什么」的顺序。不求深入，只求「知道有这个东西、大概干什么用」。

2.1 节点与集群

Vertica 跑在多台服务器上，这些服务器组成一个集群（Cluster）。 每台服务器叫一个节点（Node）。

比喻：集群就像一个搬家团队——一张沙发一个人搬不动，三个工人一起抬就搬动了。你的数据就是那张沙发。

日常中，你会用 SELECT * FROM nodes; 查看集群有哪些节点、各自状态如何。

想了解节点规划和硬件选型，详见 Vertica 数据库硬件配置指南

---

2.2 投影（Projection）

Projection 是 Vertica 中数据物理存储的形式。 它有点像传统数据库中的「物化视图 + 索引」的合体——数据以特定的排序和列集合存储在磁盘上。

和传统数据库的关键区别：传统数据库里你建一张 CREATE TABLE，数据就按一种方式存。在 Vertica 中，一张逻辑表可以有多个 projection，每个 projection 可以按不同的列排序、包含不同的列子集、以不同的方式分布在节点上。查询优化器会自动选择最适合当前查询的 projection。

比喻：传统数据库的「表」就像一本书，只有一种目录。Vertica 的 projection 就像给同一本书做了多套索引——按作者排一本、按主题排一本、按出版日期排一本。你来查「2020 年出版的书」，优化器直接拿按日期排的那本。

日常中，你建表时 Vertica 会自动创建默认 projection（superprojection），一般不需要手动管。性能调优时才会涉及 projection 设计。

深入理解 projection 设计哲学，详见 MPP 物化视图与投影的设计哲学

---

2.3 分段（Segmentation）

Segmentation 决定了数据如何在集群节点间分布。 建表时用 SEGMENTED BY HASH(column) 指定按哪一列的 hash 值来分数据。

比喻：想象你把 100 张扑克牌分给 4 个人——按「花色」分段，所有红桃给 A，所有黑桃给 B。这样当你问「谁拿着红桃 K」，你不需要问所有人，直接问 A 就行。

Hash 分段的关键好处：相同 key 的数据落在同一节点。如果两张表按同一个列分段（如都按 customer_id），那么同一个客户的数据在同一节点上，JOIN 时不需要跨节点搬运数据——这叫 Local Join，性能最好。

日常中，建表时需要考虑：这张表以后最常和谁 JOIN？用哪个列做分段键能减少数据搬运？

深入理解分段策略，详见 MPP 数据分布策略 — 从 Hash 分段到一致性哈希的工程实践

---

2.4 ROS 与 WOS

版本说明：Vertica 12.0 起 WOS 已弃用，COPY 默认直接写 ROS。以下保留 WOS 概念供老版本用户参考。

Vertica 的数据存储分两种形态：

• ROS（Read Optimized Store，读优化存储）：数据经过排序、编码、压缩后写入磁盘的最终形态。查询极快。现代版本的 COPY 默认直接将数据写入 ROS。
• WOS（Write Optimized Store，写优化存储，已弃用）：老版本中 INSERT / UPDATE 等小量写入先放在内存中的 WOS（写入快但查询慢），再由 Tuple Mover 搬到 ROS。Vertica 12.0 起已移除。

比喻：ROS 是图书馆的书架区——书按分类号排得整整齐齐，找起来快。WOS（如果你在老版本上）是还书箱——还回来的书先堆在箱子里，管理员（Tuple Mover）每隔一段时间把书归架。

日常中，现代版本上 COPY 加载的数据直接进入 ROS，可以立即高效查询。

---

2.5 Tuple Mover

Tuple Mover 是 Vertica 的后台进程，负责对 ROS 容器进行合并优化和清理过期数据。

它做三件事：

1. Moveout（老版本）：老版本中把 WOS 数据搬到 ROS。Vertica 12.0 起 WOS 已弃用，此步骤不再存在。
2. Mergeout：把多个小的 ROS 容器合并成更大的容器（减少文件碎片，提升查询性能）
3. Purge：清理被标记为删除的过期数据（在 AHM 推进后生效）

比喻：Tuple Mover 就是图书馆的管理员——每天闭馆后把散落的书整理好（mergeout），把报废的书下架（purge）。

日常中，Tuple Mover 全自动运行，通常不需要手动干预。如果发现磁盘空间不释放或查询变慢，可能和 Tuple Mover 的工作状态有关。

详见 Tuple Mover 最佳实践完全指南

---

2.6 Epoch

Epoch 是 Vertica 的事务版本号机制。 类似于传统数据库的 MVCC（多版本并发控制），每次数据变更（COPY、INSERT、DELETE 等）都会推进 epoch 号。查询只能看到在本查询开始前已提交的数据。

比喻：epoch 就像 Git 的 commit 号。每次提交产生一个新版本，你 git checkout 到某个版本看到的是那个时刻的快照。Vertica 的查询也是——查询开始时记录当前 epoch，整个查询过程看到的都是这个时刻的数据快照，不受并发写入影响。

日常中，epoch 对你透明——不需要手动管理。了解它有助于理解 Vertica 的「DELETE 为什么不是即时释放空间」「为什么需要 AHM（Ancient History Mark）」这类问题。

详见 Vertica Epoch 机制详解

---

2.7 K-Safety

K-Safety 是 Vertica 的数据副本容错机制。 K-Safe=1 意味着每个 projection 的数据都有两份副本（buddy projection），分布在不同的节点上。任意 1 个节点宕机，集群可以继续正常运转。

比喻：K-Safety 就像给重要文件做备份——原件放办公室电脑，备份放家里的 NAS。办公室电脑坏了，你还能从家里拿到文件。

K-Safety 取值范围为 0、1、2，对应数据副本数为 1、2、3：

K-Safe	副本数	可容忍宕机节点数	最少节点数	说明
0	1	0	1	无容错，任意节点宕机集群不可用
1	2	1	3	生产环境推荐值，每份数据存两份 buddy
2	3	2	5	高可用场景，任意两台节点宕机集群仍可用

K-Safety 上限受节点数约束：$\text{max_k} = \lfloor (N-1)/2 \rfloor$。例如 3 节点最大 K-Safe=1，5 节点最大 K-Safe=2。

日常中，K-Safety 在创建数据库时设定（admintools create_db 时选择），之后可以通过命令调整。

详见 K-Safety 最佳实践

---

2.8 Eon vs Enterprise 模式

Vertica 数据库有两种运行模式：

	Enterprise 模式	Eon 模式
数据存储	各节点本地磁盘	共享对象存储（S3/MinIO/Pure Storage）
计算与存储	耦合	分离
扩缩容	需要 rebalance 数据	弹性扩缩（节点即插即用）
适用场景	硬件固定、本地盘性能要求高	云环境、负载波动大、需要弹性
入门推荐	✅ 安装最简单，单节点可跑	需要额外配置对象存储

比喻：Enterprise 模式就像每个人有自己的书柜（数据在本地），Eon 模式就像所有人共用一个图书馆（数据在共享存储）。

日常选择：学习、测试、单节点环境用 Enterprise 模式。上了云、需要弹性扩缩用 Eon 模式。

来源：Vertica 26.2 文档 "Eon vs. Enterprise Mode"

---

3. 动手实操 — 你的第一条 Vertica SQL

如果你已经有 Vertica 环境，打开 vsql 跟着敲。如果还没有，先看 Vertica 单节点安装部署完全指南 搭一套。

本节使用一个贯穿的示例——一张销售表 sales。跟着走完，你会完成建表→加载数据→查询→看执行计划的完整流程。

3.1 连接数据库

vsql -h <主机IP> -U dbadmin -d <数据库名>

输入密码后，提示符变为 =>，表示你已连上 Vertica。

3.2 查看集群状态

SELECT node_name, node_state, node_address FROM nodes;

预期输出类似：

     node_name      | node_state | node_address
--------------------+------------+--------------
 v_vmart_node0001   | UP         | 10.0.0.1
 v_vmart_node0002   | UP         | 10.0.0.2
 v_vmart_node0003   | UP         | 10.0.0.3
(3 rows)

• UP 表示节点正常运行。如果看到 DOWN，说明有节点宕机。
• 输出了 3 行说明你的集群有 3 个节点。
• 如果是单节点环境，只会看到 1 行——这也是正常的。

3.3 创建一张表

CREATE TABLE sales (
    id          INTEGER,
    product     VARCHAR(50),
    category    VARCHAR(30),
    amount      NUMERIC(10,2),
    sale_date   DATE
)
SEGMENTED BY HASH(id) ALL NODES;

解读：

• SEGMENTED BY HASH(id)：按 id 列的 hash 值把数据分布到所有节点。同一个 id 的数据一定落在同一个节点上。
• ALL NODES：数据在所有节点上都有分布（而非只放在某一个节点上）。
• 如果不写 SEGMENTED BY，Vertica 也会自动选择分段键（通常选取最多 8 个字段做排序分段），数据默认在所有节点上分布。不过建议显式指定分段键以确保可控。

3.4 加载数据

先准备一个 CSV 文件 /tmp/sales.csv：

id,product,category,amount,sale_date
1,Widget,Electronics,99.99,2026-01-15
2,Gadget,Electronics,149.50,2026-01-16
3,Thingy,Home,29.99,2026-01-17
4,Doodad,Home,9.99,2026-01-18
5,Widget,Electronics,99.99,2026-02-01

COPY sales FROM LOCAL '/tmp/sales.csv' DELIMITER ',' SKIP 1;

解读：

• COPY ... FROM LOCAL 从本地文件加载数据到表。Vertica 中批量加载用 COPY 而非 INSERT——COPY 会并行处理并直接生成 ROS 文件，性能远超逐行 INSERT。
• DELIMITER ',' 指定 CSV 分隔符。
• SKIP 1 跳过文件第一行。因为 CSV 第一行是列名（id,product,category,amount,sale_date），不是数据，跳过它可以避免 Vertica 尝试将列名行当成数据行解析（导致类型错误或脏数据）。

如果文件在远程Vertica服务器上，可以用 COPY ... FROM 'path' ON ANY NODE。

官方文档：COPY

3.5 执行查询

-- 按产品汇总销售额
SELECT product, SUM(amount) AS total_sales, COUNT(*) AS cnt
FROM sales
GROUP BY product
ORDER BY total_sales DESC;

预期输出：

 product | total_sales | cnt
---------+-------------+-----
 Widget  |      199.98 |   2
 Gadget  |      149.50 |   1
 Thingy  |       29.99 |   1
 Doodad  |        9.99 |   1
(4 rows)

3.6 看执行计划

在执行查询前加 EXPLAIN，可以看优化器怎么执行这条 SQL——这是理解 MPP 执行机制的重要窗口：

EXPLAIN
SELECT product, SUM(amount) AS total_sales, COUNT(*) AS cnt
FROM sales
GROUP BY product
ORDER BY total_sales DESC;

输出（简化摘录关键行）：

------------------------------
 QUERY PLAN DESCRIPTION:
 ...
 Access Path:
 +-GROUPBY HASH (LOCAL RESEGMENT GROUPS)
 |  Group By: sales.product
 |  Execute on: ALL NODES
 ...

怎么读执行计划：

• Execute on: ALL NODES：这个查询在所有节点上并行执行——这就是 MPP 的核心价值。
• 如果看到 Execute on: Query Initiator，说明只在单个节点上执行（可能是表没有分段，数据全在一个节点上）。
• GROUPBY HASH 表示用 hash 方式做分组聚合。
• 执行计划中能看到 JOIN 策略（LOCAL / BROADCAST / RESEGMENT）、数据量估算等信息。

想系统学习执行计划分析，详见 Vertica 性能调优 - 1 如何阅读执行计划

3.7 查看存储情况

SELECT projection_basename,
       CASE WHEN BOOL_AND(is_segmented)
            THEN SUM(row_count) / COUNT(DISTINCT p.projection_name)
            ELSE MAX(row_count)
       END AS rows,
       SUM(used_bytes) / 1024 / 1024 AS size_mb
FROM projection_storage ps
JOIN (SELECT DISTINCT projection_id, projection_name, is_segmented
      FROM v_catalog.projections) p
  ON ps.projection_id = p.projection_id
WHERE anchor_table_name = 'sales'
GROUP BY projection_basename;

SEGMENTED 表：各节点各存一部分数据，SUM / COUNT(DISTINCT projection_name) 消除 buddy projection 翻倍。UNSEGMENTED 表：每节点存全量副本，取 MAX(row_count) 即真实行数。used_bytes 是叠加值无需消重。

预期输出类似：

 projection_basename | rows | size_mb
---------------------+------+---------
 sales_super         |    5 |    0.02
(1 row)

解读：

• sales_super 是建表时 Vertica 自动创建的默认 projection（superprojection），包含表的所有列。
• size_mb 较小是因为数据量少；正式环境中 TB 级数据经过列存压缩后通常是原始大小的 1/3 到 1/10。

---

4. 日常操作速查

操作	命令	说明
连接数据库	vsql -h <host> -U dbadmin -d <db>	默认端口 5433
退出 vsql	\q
查看所有节点	SELECT * FROM nodes;	重点关注 node_state
查看所有表	\dt	vsql 元命令
查看表结构	\d sales	显示列名、类型
查看 projection	SELECT * FROM projections WHERE anchor_table_name='sales';	看有哪些 projection
查看磁盘使用	SELECT sum(used_bytes)/1024^3 AS gb FROM projection_storage;	总磁盘占用
查看正在运行的查询	SELECT * FROM query_requests WHERE is_executing=true;	定位慢查询
终止查询	SELECT CLOSE_SESSION('<session_id>');	session_id 来自 query_requests
检查 K-Safety	SELECT current_fault_tolerance FROM system;	0 表示无容错，1 表示可容忍 1 节点故障

---

5. 延伸阅读 — 下一步去哪

• 想在自己机器上装一套：→ Vertica 单节点安装部署完全指南 - 从头搭建一个 Vertica 环境，跟着做完就能用。
• 想搭 3 节点集群体验分布式：→ Vertica 3 节点集群安装部署完全指南
• 想深入理解 MPP 设计原理：把本文提到的每个概念展开纵深，从设计哲学到生产 case。
  • MPP 列存引擎的架构设计哲学
  • MPP 并行执行引擎原理
• 日常运维遇到问题：→ Vertica 错误日志解读与常见错误处理
• 性能优化：→ Vertica 性能调优 - 1 如何阅读执行计划
• Vertica 数据库硬件配置指南：在正式部署前，了解硬件选型和配置建议。