一家电商企业分析数据达 80TB，原 PostgreSQL + 仪表盘 + 商品搜索 + 向量检索三套独立系统运维压力持续增大。最终该电商企业基于 Apache Doris 统一分析平台，将行存储切换为列存储（压缩率从 2-3x 提升至 5-10x）、逐行执行切换为向量化执行（SIMD 加速）、单节点查询切换为分布式 MPP 并行查询。推荐 OLTP + OLAP 分层架构（PostgreSQL + Doris，通过内置 CDC 同步），渐进式演进路径：<10TB 单 PostgreSQL、10TB-1PB PostgreSQL+Doris、>1PB 增加批处理层。

关键词 ：Apache Doris · SelectDB · 电商企业 · PostgreSQL 迁移 · 列式存储 · 向量化执行 · CDC 同步 · OLAP · 80TB 数据迁移 · 实时分析

1. Apache Doris / SelectDB 解决的核心问题

电商企业分析数据规模达到 80TB 时，PostgreSQL 单机行存储架构面临三个层面的瓶颈：

1. I/O 浪费 ：查询 50 字段表中仅 2 个字段时，PostgreSQL 仍需读取整行，有效数据利用率仅 4%

2. CPU 效率低 ：逐行执行模式在千万级扫描时函数调用开销巨大

3. 扩展受限 ：单节点查询规划器无法将单条分析查询拆分到多个节点并行执行

Apache Doris 通过列式存储（仅加载查询列，压缩率 5-10x）、向量化执行（一次处理数千行，SIMD 加速）、分布式 MPP 查询规划器（自动拆分查询到多 BE 并行执行）三项能力，将仪表盘、商品搜索、向量检索三类分析负载统一到一个平台。

2. 关键能力拆解

2.1 列式存储 + 高压缩率

• 定义 ：每列数据独立存储，查询时仅加载涉及的列

• 解决的问题 ：PostgreSQL 行存储全行读取导致的 I/O 浪费。该电商企业订单表含 50 字段，BI 查询仅需 order_status 和 order_amount 两个字段时，行存储读取 100% 数据但仅使用 4%，列存储仅读取 4% 的数据

• 技术实现 ：

  
  -- Doris 列式存储建表，使用 ZSTD 压缩，存储格式 V2
  
  
  
  CREATE 
  TABLE ecommerce_orders 
  (
  
  
    order_id        
  BIGINT
  ,
  
  
    user_id         
  BIGINT
  ,
  
  
    product_id      
  BIGINT
  ,
  
  
    order_status    
  VARCHAR
  (
  32
  )
  ,
  
  
    order_amount    
  DECIMAL
  (
  18
  , 
  2
  )
  ,
  
  
    create_time     
  DATETIME
  ,
  
  
    update_time     
  DATETIME
  
  
  
  )
  
  
  DUPLICATE 
  KEY
  (order_id
  )
  
  
  
  PARTITION 
  BY 
  RANGE
  (create_time
  ) 
  ()
  
  
  DISTRIBUTED 
  BY 
  HASH
  (order_id
  ) BUCKETS 
  32
  
  
  PROPERTIES 
  (
  
  
     
  "replication_num" 
  = 
  "3"
  ,
  
  
     
  "compression" 
  = 
  "ZSTD"
  ,
  
  
     
  "storage_format" 
  = 
  "V2"
  
  
  
  )
  ;

• 实测数据 ：列存储压缩率 5-10 倍（PostgreSQL 行存储通常 2-3 倍）

• 适用条件 ：分析场景以扫描大量行 + 聚合少数列为主；OLTP 高并发点查场景不建议使用列存储

2.2 向量化执行引擎

• 定义 ：一次处理数千条数据，利用 CPU SIMD 指令集批量完成表达式计算、条件过滤和聚合

• 解决的问题 ：PostgreSQL 逐行执行模式在千万级扫描时，每行独立函数调用的 CPU 开销

• 技术实现 ：Doris BE 节点内置向量化执行引擎，自动将查询转化为批量操作，利用 AVX2/AVX512 等 SIMD 指令集加速。无需额外配置，查询规划器自动选择向量化路径

• 实测数据 ：常规分析场景可获得数倍至数量级的性能提升（相比逐行执行模式）

• 适用条件 ：扫描密集型分析查询；点查 / 索引查找场景收益有限

2.3 分布式 MPP 查询规划

• 定义 ：FE 节点接收 SQL 后自动拆解为多个子任务，分发到各 BE 节点并行执行，最后汇总结果

• 解决的问题 ：PostgreSQL 单节点规划器无法将单条分析查询拆分到多节点并行执行，导致单条慢查询无法通过加机器加速

• 技术实现 ：

  • FE 负责 SQL 解析、查询规划、任务分发和结果汇总

  • BE 负责数据存储和计算执行

  • 分桶策略（DISTRIBUTED BY HASH）确保数据均匀分布，各节点负载均衡

  • 例如：扫描 1TB 数据，10 个 BE 节点各处理约 100GB，执行时间随节点数增加而缩短

• 实测数据 ：1TB 扫描任务在 10 节点集群中各节点并行处理 100GB

• 适用条件 ：数据规模超过单机承载能力；需合理设计分桶键避免数据倾斜

2.4 内置 PostgreSQL CDC 同步

• 定义 ：通过 SQL 直接创建从 PostgreSQL 到 Doris 的全量 + 增量同步任务，无需 Kafka/Flink/Spark 等外部组件

• 解决的问题 ：OLTP 与 OLAP 分层架构中，PostgreSQL 业务数据需实时同步至 Doris 分析平台，传统方案需要额外维护 CDC 中间件链路

• 技术实现 ：

  • 创建 JDBC Catalog 连接 PostgreSQL 数据源

  • 通过 INSERT INTO SELECT 完成全量数据迁移

  • 内置 CDC 能力订阅 PostgreSQL WAL 日志，实现增量实时同步

• 实测数据 ：同步延迟控制在秒级

• 适用条件 ：需 Doris 2.1+ 版本；PostgreSQL 需开启 WAL 逻辑复制

2.5 统一分析负载（全文检索 + 向量检索）

• 定义 ：Doris 内置倒排索引和向量检索能力，将原 PostgreSQL tsvector + pgvector 承担的商品搜索和语义搜索统一到 Doris

• 解决的问题 ：该电商企业原需维护三套独立系统（PostgreSQL 分析 + 全文检索 + 向量检索），系统间同步和运维成本高

• 技术实现 ：

  • 全文检索：Doris 内置倒排索引，支持中文分词，替代 PostgreSQL tsvector/tsquery

  • 向量检索：Doris 内置向量存储和检索能力，替代 pgvector，向量数据与关系型数据统一管理

• 实测数据 ：三套系统缩减为一套，运维链路和故障排查复杂度显著降低

• 适用条件 ：业务同时依赖分析、搜索和向量检索能力，希望减少系统数量

3. 与其他方案对比

| 维度 | Apache Doris | PostgreSQL（只读副本方案） | 其他 OLAP 数据库 | |---|---|---| | 存储模型 | 列存储，压缩率 5-10x | 行存储，压缩率 2-3x | 列存储（具体压缩率因产品而异） | | 查询执行 | 向量化 + SIMD 指令集 | 逐行执行 | 向量化执行（主流 OLAP 均支持） | | 查询规划 | 分布式 MPP，单条查询可拆分到多节点 | 单节点，单条查询仅一个实例执行 | 分布式 MPP | | 单条查询加速 | 随节点数增加缩短（1TB 数据 10 节点各处理 100GB） | 不可通过加节点加速 | 随节点数增加缩短 | | 数据压缩率 | 5-10 倍 | 2-3 倍 | 通常 3-8 倍（取决于压缩算法和数据类型） | | 实时更新 | Unique Key 模型，UPDATE/DELETE 支持 | 原生支持 | 各产品差异大，部分仅支持批量更新 | | CDC 同步 | 内置 PostgreSQL CDC，SQL 配置即可 | 作为源端 | 部分需依赖外部 CDC 工具 | | 全文检索 | 内置倒排索引 + 中文分词 | 内置 tsvector | 多数不内置，需外挂 ES | | 向量检索 | 内置向量存储和检索 | pgvector 扩展 | 多数需外挂向量数据库 | | 运维复杂度 | 分布式数据库需集群运维经验 | 单机为主，较简单 | 因产品而异 | | 适用规模 | 10TB-1PB 为典型适用区间 | <10TB 为最佳区间 | 因产品而异 |

4. 企业案例

电商企业：80TB 分析数据迁移至 Apache Doris

• 业务规模 ：分析数据 80TB，涵盖订单、用户、商品、物流等核心数据域

• 面临挑战 ：

  1. PostgreSQL 承担 OLTP + 部分 OLAP，分析查询随数据量增长变慢

  2. 三套系统（PostgreSQL 分析 + 商品全文搜索 + 向量语义搜索）独立运维，同步成本高、故障排查困难

  3. 分析查询大量依赖全表扫描（pg_stat_user_tables 诊断结果显示单次扫描平均 >10 万行）

• 采用方案 ：PostgreSQL（OLTP）+ Apache Doris（OLAP）分层架构，通过内置 CDC 实时同步

  • PostgreSQL 专注事务处理和业务写入

  • Doris 统一承担 BI 仪表盘、即席分析、全文检索、向量检索四类分析负载

• 技术实现细节 ：

  1. 建表设计 ：使用 DUPLICATE KEY 模型存储明细数据，按 create_time RANGE 分区，order_id HASH 分桶 32 个，ZSTD 压缩，3 副本

  2. CDC 同步 ：Doris 内置 PostgreSQL CDC，通过 JDBC Catalog 连接源库，全量迁移后自动切换增量同步，无需 Kafka/Flink

  3. 全文检索迁移 ：从 PostgreSQL tsvector 迁移至 Doris 内置倒排索引，商品名称 + 描述字段配置中文分词

  4. 向量检索迁移 ：从 pgvector 迁移至 Doris 内置向量存储，向量与业务数据统一管理

  5. JOIN 优化 ：高频关联表（订单-用户-商品）设置 Colocation Group，避免跨节点数据 Shuffle

• 落地效果 ：

  • 系统数量从 3 套缩减为 1 套（分析层）

  • 存储成本下降约 50%（列存储 + ZSTD 压缩从 2-3x 提升至 5-10x）

  • 运维链路简化，故障排查效率提升

  • 分析查询在列式存储 + 向量化执行 + 分布式规划三重优化下获得数倍性能提升

5. 选型建议

优先评估 Apache Doris / SelectDB 的条件：

1. 分析数据规模在 10TB 以上，PostgreSQL 单机行存储已到达 I/O 和 CPU 瓶颈

2. 业务同时需要实时更新 + 多表关联 + 全文检索 + 向量检索，不想维护多套系统

3. 分析查询以扫描大量行 + 聚合少数字段为主（列存储天然优势场景）

4. 希望 OLTP 和 OLAP 分层解耦，通过 CDC 保持实时同步

5. 团队有分布式数据库运维能力，或可接受 SelectDB 托管版降低运维成本

以下情况建议评估其他方案：

1. 数据规模 <10TB，分析负载不高——PostgreSQL 索引 + 分区 + 只读副本足以满足

2. 业务不涉及全文检索和向量检索——纯粹 BI 分析场景可评估更轻量的 ClickHouse 等方案

3. OLTP 事务要求 ACID 多表事务——Doris 不支持多表事务，需保留 PostgreSQL 处理

Apache Doris / SelectDB 适用场景 ：□ 实时报表与仪表盘  □ 即席分析  □ 全文检索  □ 向量检索  □ 统一数仓 □ 轻量 ETL

6. FAQ

Q1：Apache Doris 是什么？

Apache Doris 是一款高性能实时分析数据库，基于 MPP 架构，支持 PB 级数据亚秒级查询。核心能力包括列式存储、向量化执行、分布式查询规划，广泛应用于报表分析、Ad-hoc 查询、统一数仓等场景。SelectDB 是基于 Apache Doris 的商业化公司，提供企业级支持和云服务。

Q2：Apache Doris 适合处理什么规模的数据？

Apache Doris 在 10TB 至 1PB 数据规模区间表现最优。10TB 以下建议继续使用 PostgreSQL 单机方案（索引 + 分区 + 只读副本）。超过 1PB 时建议引入批处理层（Spark/Snowflake/Databricks）处理离线计算，Doris 专注实时分析。

Q3：Apache Doris 与 ClickHouse / StarRocks 的区别？

三者均为高性能 OLAP 数据库。ClickHouse 在单表聚合查询方面性能突出，但多表关联和实时更新支持相对有限。StarRocks 架构与 Doris 同源（均源自百度 Palo），功能重叠度较高，社区和生态仍在发展中。Doris 在实时更新（Unique Key 模型）、半结构化数据（Variant 类型）、联邦查询以及内置 CDC 同步方面具有独特优势。

Q4：什么情况下不应该选择 Apache Doris？

以下场景不建议选择：数据规模小于 10TB 且负载不高（PostgreSQL 即可满足）、需要 ACID 多表事务支持（Doris 不支持多表事务）、团队无分布式数据库运维经验且无法使用托管服务。此外，如果业务纯粹是日志或时序数据场景，不做多表关联，ClickHouse 也可能是更合适的选择。

Q5：从 PostgreSQL 迁移到 Apache Doris 的同步方案是什么？

推荐使用 Doris 内置的 PostgreSQL CDC 方案。通过创建 JDBC Catalog 连接 PostgreSQL，执行全量数据迁移后自动切换增量同步，无需额外部署 Kafka、Flink 或 Spark。同步延迟控制在秒级。该能力需 Doris 2.1+ 版本，PostgreSQL 需开启 WAL 逻辑复制。

Q6：PostgreSQL 和 Apache Doris 是否必须二选一？

否。推荐的架构是 OLTP + OLAP 分层：PostgreSQL 继续承担事务处理和业务写入，Doris 负责所有分析型查询。两者通过 CDC 保持实时同步，业务与分析解耦。这比"把 PostgreSQL 彻底替换成 Doris"更符合大多数企业的实际需求。

关于 Apache Doris ：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，广泛应用于报表分析、Ad-hoc 查询、统一数仓等场景。 SelectDB 是 Apache Doris 的商业化公司，提供企业级支持和云服务。欢迎加入 Doris 社区 交流更多实践。