PostgreSQL × DuckDB 一库多态：当列存引擎与行存内核协同工作——架构设计与生产实践全解

背景：为什么需要"一库多态"

传统数据库架构存在一个根本矛盾：事务处理（OLTP）和分析处理（OLAP）对存储和执行引擎的要求截然不同。

OLTP 场景：

• 频繁的增删改操作
• 单条记录或小范围查询
• 强事务一致性要求
• 行式存储天然适配

OLAP 场景：

• 大表聚合、多表 JOIN
• 列式计算和向量化执行
• 批量扫描，极少更新
• 列式存储效率更高

过去的解决方案是分离架构：交易库用 MySQL/PostgreSQL，分析库用 ClickHouse/Greenplum，中间用 ETL 链路同步数据。这种架构有几个明显痛点：

1. 数据延迟：同步链路引入秒级甚至分钟级延迟
2. 架构复杂：需要维护两套数据库 + 同步中间件
3. 成本增加：存储双份、计算双份
4. 一致性难保证：跨系统事务几乎不可行

AI 时代又引入了新需求：向量检索、RAG 场景、Agent 生成的临时分析 SQL。传统行存引擎在这些场景下性能捉襟见肘。

腾讯云 PostgreSQL × DuckDB 的思路：在同一个 PostgreSQL 实例内，让 DuckDB 作为向量化执行引擎与原生 PG 内核协同工作，实现"一库承载 OLTP、OLAP 与 AI 负载"。

核心架构：DuckDB 如何与 PostgreSQL 协同

双引擎架构设计

┌─────────────────────────────────────────────────────────────┐
│                      PostgreSQL 实例                         │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────────┐         ┌─────────────────────────┐   │
│  │  PG 原生引擎     │         │   DuckDB 引擎            │   │
│  │  (行存 + B-Tree) │◄───────►│   (列存 + 向量化执行)     │   │
│  └─────────────────┘         └─────────────────────────┘   │
│           │                            │                    │
│           ▼                            ▼                    │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              统一存储层（共享表数据）                   │   │
│  │   行存格式（事务主副本） + 列存副本（分析加速）          │   │
│  └─────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

关键设计点：

1. 透明路由：系统自动识别查询类型，分析类查询路由到 DuckDB，事务类查询走原生 PG 路径
2. 数据同步：DDL 变更秒级同步到列存端，无需手动刷新
3. 生态兼容：SQL 语法、权限模型、事务语义、扩展（pgvector、PostGIS）完全兼容

启用方式：一条 SET 语句

-- 开启 DuckDB 引擎
SET duckdb.enabled = true;

-- 后续分析查询自动走 DuckDB
SELECT
    date_trunc('day', created_at) as day,
    COUNT(*) as orders,
    SUM(amount) as total_amount,
    AVG(amount) as avg_amount
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY date_trunc('day', created_at)
ORDER BY day;

这就是"零迁移成本"的核心：业务代码一行不用改，只是多了一条 SET 语句。

向量化执行原理：为什么 DuckDB 能快几个数量级

列式存储 vs 行式存储

假设一张表有 10 列、1000 万行，查询只需要 3 列做聚合：

行式存储：

• 每行数据连续存储
• 读取时必须把整行都读出来
• 10 列 × 1000 万 × 8 字节 = 800MB 扫描
• 实际只需要 240MB，但被迫读了 800MB

列式存储：

• 每列数据连续存储
• 只读取需要的列
• 3 列 × 1000 万 × 8 字节 = 240MB 扫描
• I/O 减少了 70%

# 行式存储示意（伪代码）
row_storage = [
    [col1, col2, col3, ..., col10],  # 第1行
    [col1, col2, col3, ..., col10],  # 第2行
    ...
]

# 列式存储示意
column_storage = {
    'col1': [val1, val2, val3, ...],  # 第1列所有值
    'col2': [val1, val2, val3, ...],  # 第2列所有值
    ...
}

向量化执行：SIMD 指令级并行

传统火山模型（Volcano Iterator）是逐行处理：

// 传统执行模型伪代码
for each row in table:
    if row.filter_condition:
        result = aggregate(row.column)

向量化执行是批量处理，利用 CPU 的 SIMD 指令：

// 向量化执行伪代码
for batch in table:  // 每次处理 1024 行
    filter_mask = simd_filter(batch.columns, condition)
    filtered = simd_select(batch, filter_mask)
    result = simd_aggregate(filtered.target_column)

性能差异来源：

DuckDB 的向量化执行引擎可以在单核上实现 5-10 倍的性能提升，多核并行后差距更大。

实战场景一：RAG 检索加速

传统 RAG 架构的痛点

┌─────────┐    ┌─────────────┐    ┌─────────────┐    ┌──────────┐
│ 业务库   │───►│ 同步链路     │───►│ 向量数据库   │───►│ LLM      │
│(PostgreSQL)│    │ (ETL/CDC)  │    │(Milvus/Pinecone)│    │          │
└─────────┘    └─────────────┘    └─────────────┘    └──────────┘

问题：

1. 数据要同步，延迟不可避免
2. 元数据过滤 + 向量检索需要跨系统 JOIN
3. 两套系统，运维成本翻倍

PostgreSQL × DuckDB 的 RAG 方案

-- 创建带向量的表
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT,
    metadata JSONB,
    embedding VECTOR(1536)
);

-- 创建 HNSW 向量索引（vss 扩展）
CREATE INDEX idx_embedding ON documents
USING hnsw (embedding vector_cosine_ops);

-- 一条 SQL 完成向量召回 + 元数据过滤 + 结果排序
SET duckdb.enabled = true;

SELECT
    id,
    content,
    metadata->>'category' as category,
    1 - (embedding <=> query_vector) as similarity
FROM documents
WHERE
    metadata->>'category' IN ('tech', 'news')
    AND metadata->>'status' = 'published'
ORDER BY embedding <=> query_vector
LIMIT 10;

关键优势：

1. 向量召回 + 元数据过滤在一条 SQL 内完成，无需跨系统
2. DuckDB 加速聚合和排序，复杂查询近实时返回
3. 数据一致性天然保证，因为就在同一个事务内

性能对比实测

假设 documents 表 100 万行，每行 1536 维向量：

实战场景二：Agent 数据分析

LangChain SQL Agent 的默认选择

LangChain 的 SQL Agent Toolkit 已将 DuckDB 作为 Text-to-SQL 的默认目标库。为什么？

from langchain.agents import create_sql_agent
from langchain.sql_database import SQLDatabase

# DuckDB 作为 Agent 分析的目标库
db = SQLDatabase.from_uri("duckdb:///analytics.db")

agent = create_sql_agent(
    llm=llm,
    db=db,
    agent_type="openai-tools",
    verbose=True
)

# Agent 接收自然语言问题
agent.run("上个月每个产品类别的销售额是多少？增长率如何？")

DuckDB 适合 Agent 分析的原因：

1. 零依赖启动：单文件数据库，无需独立服务
2. 聚合快速返回：向量化执行让临时分析 SQL 近实时
3. SQL 方言统一：与 PostgreSQL 兼容度高，LLM 生成更准确

在 PostgreSQL × DuckDB 中实现 Agent 分析

import psycopg2
from openai import OpenAI

client = OpenAI()

def agent_analyze(question: str) -> str:
    # 1. LLM 生成 SQL
    prompt = f"""
    用户问题：{question}

    请生成 PostgreSQL 查询语句。
    表结构：
    - orders(id, user_id, product_id, amount, status, created_at)
    - products(id, name, category, price)
    - users(id, name, region, created_at)
    """

    sql = client.chat.completions.create(
        model="gpt-4",
        messages=[{"role": "user", "content": prompt}]
    ).choices[0].message.content

    # 2. 启用 DuckDB 引擎并执行
    conn = psycopg2.connect("postgresql://...")
    cursor = conn.cursor()

    cursor.execute("SET duckdb.enabled = true")
    cursor.execute(sql)

    result = cursor.fetchall()

    # 3. 结果返回给 LLM 总结
    summary = client.chat.completions.create(
        model="gpt-4",
        messages=[{
            "role": "user",
            "content": f"基于查询结果回答问题：{question}\n\n数据：{result}"
        }]
    ).choices[0].message.content

    return summary

实际场景：

用户: 帮我分析一下上周各地区的新增用户趋势

Agent 生成的 SQL:
SELECT
    date_trunc('day', created_at) as day,
    region,
    COUNT(*) as new_users
FROM users
WHERE created_at >= CURRENT_DATE - INTERVAL '7 days'
GROUP BY date_trunc('day', created_at), region
ORDER BY day, region;

执行时间: 120ms（1000 万用户表）

实战场景三：HTAP 混合负载

场景描述

一个电商系统同时承载：

1. 交易写入：订单创建、状态更新（OLTP）
2. 实时报表：每分钟刷新的销售大盘（OLAP）
3. 临时分析：运营提出的临时统计需求（OLAP）

传统方案需要两套系统，现在用 PostgreSQL × DuckDB 一套搞定。

表结构设计

-- 订单表（主表）
CREATE TABLE orders (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    amount DECIMAL(10, 2) NOT NULL,
    status VARCHAR(20) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 订单明细表
CREATE TABLE order_items (
    id BIGSERIAL PRIMARY KEY,
    order_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    quantity INT NOT NULL,
    unit_price DECIMAL(10, 2) NOT NULL,
    FOREIGN KEY (order_id) REFERENCES orders(id)
);

-- 创建索引（事务查询用）
CREATE INDEX idx_orders_user ON orders(user_id);
CREATE INDEX idx_orders_status ON orders(status);
CREATE INDEX idx_orders_created ON orders(created_at);

混合负载实战

-- 场景1: 事务写入（走原生 PG 引擎）
BEGIN;
INSERT INTO orders (user_id, product_id, amount, status)
VALUES (12345, 67890, 299.00, 'pending');

INSERT INTO order_items (order_id, product_id, quantity, unit_price)
VALUES (currval('orders_id_seq'), 67890, 1, 299.00);
COMMIT;

-- 场景2: 实时报表（走 DuckDB 引擎）
SET duckdb.enabled = true;

SELECT
    date_trunc('hour', created_at) as hour,
    COUNT(*) as order_count,
    SUM(amount) as total_amount,
    AVG(amount) as avg_amount,
    COUNT(DISTINCT user_id) as unique_users
FROM orders
WHERE created_at >= CURRENT_DATE
GROUP BY date_trunc('hour', created_at)
ORDER BY hour;

-- 场景3: 复杂分析（走 DuckDB 引擎）
SET duckdb.enabled = true;

WITH daily_stats AS (
    SELECT
        date_trunc('day', o.created_at) as day,
        p.category,
        COUNT(DISTINCT o.user_id) as buyers,
        SUM(oi.quantity) as items_sold,
        SUM(oi.quantity * oi.unit_price) as revenue
    FROM orders o
    JOIN order_items oi ON o.id = oi.order_id
    JOIN products p ON oi.product_id = p.id
    WHERE o.status = 'completed'
      AND o.created_at >= CURRENT_DATE - INTERVAL '30 days'
    GROUP BY date_trunc('day', o.created_at), p.category
)
SELECT
    category,
    AVG(revenue) as avg_daily_revenue,
    AVG(buyers) as avg_daily_buyers,
    SUM(items_sold) as total_items
FROM daily_stats
GROUP BY category
ORDER BY avg_daily_revenue DESC;

性能数据（1000 万订单，5000 万明细）：

存储与同步机制

列存副本的组织方式

┌─────────────────────────────────────────────────────┐
│              表存储层（以 orders 表为例）             │
├─────────────────────────────────────────────────────┤
│  ┌───────────────────────────────────────────────┐  │
│  │  行存主副本（事务引擎用）                        │  │
│  │  ├── orders.heap（堆文件）                     │  │
│  │  ├── orders_pkey（主键 B-Tree）               │  │
│  │  └── idx_orders_user（二级索引）               │  │
│  └───────────────────────────────────────────────┘  │
│                        │                            │
│                        ▼                            │
│  ┌───────────────────────────────────────────────┐  │
│  │  列存副本（DuckDB 引擎用）                      │  │
│  │  ├── orders_columnar/（列存目录）              │  │
│  │  │   ├── id.bin                               │  │
│  │  │   ├── user_id.bin                          │  │
│  │  │   ├── amount.bin                           │  │
│  │  │   ├── created_at.bin                       │  │
│  │  │   └── metadata.json                        │  │
│  └───────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────┘

列存格式优势：

1. 压缩率高：相同类型数据连续存储，压缩算法效果更好
2. 投影优化：只读取需要的列，减少 I/O
3. 向量化友好：列数据天然适合 SIMD 批处理

DDL 变更同步机制

-- 新增列
ALTER TABLE orders ADD COLUMN region VARCHAR(50);

-- 秒级同步到列存端
-- 无需手动刷新，系统自动感知

同步流程：

1. DDL 操作写入 PostgreSQL WAL
2. DuckDB 引擎监听 WAL 流
3. 解析 DDL 变更，更新列存元数据
4. 后续查询自动使用新结构

同步延迟：通常在 1-3 秒内完成。

性能优化实践

1. 查询路由优化

-- 强制走原生 PG（适合小范围事务查询）
SET duckdb.enabled = false;

SELECT * FROM orders WHERE id = 12345;

-- 强制走 DuckDB（适合大表聚合）
SET duckdb.enabled = true;

SELECT COUNT(*), SUM(amount) FROM orders WHERE created_at >= '2026-01-01';

判断标准：

2. 索引策略

-- 事务查询索引（B-Tree）
CREATE INDEX idx_orders_user ON orders(user_id);
CREATE INDEX idx_orders_status_created ON orders(status, created_at);

-- 向量索引（HNSW，vss 扩展）
CREATE INDEX idx_embedding ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (M = 16, ef_construction = 64);

-- 分析查询索引（通常不需要，DuckDB 依靠列存扫描）
-- 但可以为常过滤条件建索引

3. 内存配置

-- DuckDB 内存限制
SET duckdb.memory_limit = '4GB';

-- 线程数（并发查询）
SET duckdb.threads = 8;

-- 临时目录（内存不足时溢写到磁盘）
SET duckdb.temp_directory = '/tmp/duckdb_temp';

4. 监控指标

-- 查询 DuckDB 引擎状态
SELECT * FROM duckdb_settings();

-- 查看列存表状态
SELECT
    schemaname,
    tablename,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) as total_size,
    pg_size_pretty(pg_relation_size(schemaname||'.'||tablename, 'main')) as heap_size
FROM pg_tables
WHERE schemaname NOT IN ('pg_catalog', 'information_schema');

-- 监控查询执行时间
SELECT
    query,
    calls,
    total_time / 1000 as total_time_ms,
    mean_time / 1000 as mean_time_ms
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 20;

与其他方案对比

1. vs 分离架构（PG + ClickHouse）

2. vs 内存数据库（Redis + 持久化）

3. vs 其他 HTAP 方案（TiDB、OceanBase）

选型建议：

• 数据规模 < 10TB、单实例能承载 → PG × DuckDB
• 需要强一致性、简化架构 → PG × DuckDB
• 数据规模 > 10TB、需要水平扩展 → TiDB/OceanBase
• 已有 PostgreSQL 生态、不想大改 → PG × DuckDB

生产部署建议

1. 硬件配置

推荐配置（中等规模，TB 级数据）：
- CPU: 16-32 核
- 内存: 64-128 GB
- 存储: NVMe SSD，IOPS > 50000
- 网络: 10Gbps

最低配置（小规模，< 500GB）：
- CPU: 8 核
- 内存: 32 GB
- 存储: SATA SSD
- 网络: 1Gbps

2. PostgreSQL 参数调优

-- postgresql.conf

# 内存配置
shared_buffers = 16GB
work_mem = 256MB
maintenance_work_mem = 2GB

# 并行查询
max_parallel_workers_per_gather = 4
max_parallel_workers = 8

# WAL 配置
wal_level = logical
max_wal_senders = 4
wal_keep_size = 1GB

# DuckDB 引擎配置
duckdb.memory_limit = 8GB
duckdb.threads = 8
duckdb.temp_directory = '/data/duckdb_temp'

3. 备份策略

# 基础备份（包含行存和列存）
pg_basebackup -D /backup/base -Fp -Xs -P -R

# WAL 归档
archive_mode = on
archive_command = 'cp %p /backup/wal/%f'

# PITR 恢复
restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '2026-07-22 12:00:00'

4. 监控告警

# Prometheus 告警规则示例
groups:
  - name: postgresql_duckdb
    rules:
      - alert: DuckDBMemoryHigh
        expr: duckdb_memory_usage_bytes / duckdb_memory_limit_bytes > 0.9
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "DuckDB 内存使用率过高"

      - alert: QuerySlow
        expr: pg_query_duration_seconds{quantile="0.95"} > 10
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "慢查询增多"

常见问题与解决方案

Q1: DuckDB 引擎适合所有场景吗？

不适合：

• 单行查询、小范围事务查询 → 用原生 PG
• 频繁的增删改操作 → 用原生 PG（列存不适合频繁更新）
• 复杂事务（多表关联更新）→ 用原生 PG

适合：

• 大表聚合分析
• 多表 JOIN + 聚合
• 向量检索 + 元数据过滤
• Agent 生成的临时分析 SQL

Q2: 列存副本占用多少额外存储？

通常为行存主副本的 30%-50%（因为列存压缩效果更好）。

-- 查看存储占用
SELECT
    pg_size_pretty(pg_relation_size('orders')) as heap_size,
    pg_size_pretty(pg_columnar_size('orders')) as columnar_size;

Q3: 如何判断查询是否走了 DuckDB 引擎？

-- 开启查询日志
SET log_statement = 'all';

-- 或使用 EXPLAIN
SET duckdb.enabled = true;
EXPLAIN ANALYZE SELECT COUNT(*) FROM orders;

-- 输出中会显示 "DuckDB Execution" 标识

Q4: 数据写入时会不会影响 DuckDB 查询？

不会。写入走行存主副本，DuckDB 读取列存副本，两者互不阻塞。

但写入会触发列存同步（秒级延迟），最新数据可能在 1-3 秒后才对分析查询可见。

Q5: 与 pgvector 兼容吗？

完全兼容。pgvector 在 PG 原生引擎下工作，向量检索走 pgvector，聚合分析走 DuckDB，两者可以组合使用。

-- 向量检索用 pgvector
SELECT * FROM documents
ORDER BY embedding <=> query_vector
LIMIT 10;

-- 向量检索 + 复杂聚合用 DuckDB
SET duckdb.enabled = true;
SELECT
    category,
    COUNT(*) as doc_count,
    AVG(similarity) as avg_similarity
FROM (
    SELECT
        category,
        1 - (embedding <=> query_vector) as similarity
    FROM documents
    WHERE 1 - (embedding <=> query_vector) > 0.8
) t
GROUP BY category;

总结与展望

核心价值

1. 架构简化：一套系统承载 OLTP、OLAP、AI 三类负载
2. 零迁移成本：业务代码几乎不用改
3. 强一致性：数据在同一事务内，无同步延迟
4. 成本降低：无需维护双系统

适用场景

• 数据规模 TB 级：单实例能承载
• 混合负载：既有事务处理又有分析需求
• AI 应用：RAG、Agent 分析
• PostgreSQL 生态：已有 PG 技术栈

不适用场景

• PB 级数据：需要分布式方案
• 纯分析场景：ClickHouse 等专用 OLAP 更优
• 高频写入：列存不适合频繁更新

未来演进方向

1. 更智能的路由：自动判断查询类型，无需手动 SET
2. 增量同步优化：降低 DDL 同步延迟到毫秒级
3. 分布式扩展：支持多节点的分布式列存
4. 更多 AI 能力：内置 embedding 生成、向量索引优化

参考资源

• DuckDB 官方文档
• PostgreSQL 官方文档
• pgvector 扩展
• LangChain SQL Agent
• 腾讯云 PostgreSQL 产品文档

本文约 6500 字，涵盖了 PostgreSQL × DuckDB 的架构原理、向量化执行机制、三大实战场景、性能优化、生产部署建议等内容，适合已有 PostgreSQL 基础想要了解 HTAP 演进方案的工程师阅读。