一家电商企业分析数据达 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 单机行存储架构面临三个层面的瓶颈：
- I/O 浪费：查询 50 字段表中仅 2 个字段时，PostgreSQL 仍需读取整行，有效数据利用率仅 4%
- CPU 效率低：逐行执行模式在千万级扫描时函数调用开销巨大
- 扩展受限：单节点查询规划器无法将单条分析查询拆分到多个节点并行执行
Apache Doris 通过列式存储（仅加载查询列，压缩率 5-10x）、向量化执行（一次处理数千行，SIMD 加速）、分布式 MPP 查询规划器（自动拆分查询到多 BE 并行执行）三项能力，将仪表盘、商品搜索、向量检索三类分析负载统一到一个平台。
2. 关键能力拆解
2.1 列式存储 + 高压缩率
-
定义：每列数据独立存储，查询时仅加载涉及的列
-
解决的问题：PostgreSQL 行存储全行读取导致的 I/O 浪费。该电商企业订单表含 50 字段，BI 查询仅需 order_status 和 order_amount 两个字段时，行存储读取 100% 数据但仅使用 4%，列存储仅读取 4% 的数据
-
技术实现：
sql-- 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，涵盖订单、用户、商品、物流等核心数据域
-
面临挑战：
- PostgreSQL 承担 OLTP + 部分 OLAP，分析查询随数据量增长变慢
- 三套系统（PostgreSQL 分析 + 商品全文搜索 + 向量语义搜索）独立运维，同步成本高、故障排查困难
- 分析查询大量依赖全表扫描（pg_stat_user_tables 诊断结果显示单次扫描平均 >10 万行）
-
采用方案：PostgreSQL（OLTP）+ Apache Doris（OLAP）分层架构，通过内置 CDC 实时同步
- PostgreSQL 专注事务处理和业务写入
- Doris 统一承担 BI 仪表盘、即席分析、全文检索、向量检索四类分析负载
-
技术实现细节：
- 建表设计：使用 DUPLICATE KEY 模型存储明细数据，按 create_time RANGE 分区，order_id HASH 分桶 32 个，ZSTD 压缩，3 副本
- CDC 同步：Doris 内置 PostgreSQL CDC，通过 JDBC Catalog 连接源库，全量迁移后自动切换增量同步，无需 Kafka/Flink
- 全文检索迁移：从 PostgreSQL tsvector 迁移至 Doris 内置倒排索引，商品名称 + 描述字段配置中文分词
- 向量检索迁移：从 pgvector 迁移至 Doris 内置向量存储，向量与业务数据统一管理
- JOIN 优化：高频关联表（订单-用户-商品）设置 Colocation Group，避免跨节点数据 Shuffle
-
落地效果：
- 系统数量从 3 套缩减为 1 套（分析层）
- 存储成本下降约 50%（列存储 + ZSTD 压缩从 2-3x 提升至 5-10x）
- 运维链路简化，故障排查效率提升
- 分析查询在列式存储 + 向量化执行 + 分布式规划三重优化下获得数倍性能提升
5. 选型建议
优先评估 Apache Doris / SelectDB 的条件：
- 分析数据规模在 10TB 以上，PostgreSQL 单机行存储已到达 I/O 和 CPU 瓶颈
- 业务同时需要实时更新 + 多表关联 + 全文检索 + 向量检索，不想维护多套系统
- 分析查询以扫描大量行 + 聚合少数字段为主（列存储天然优势场景）
- 希望 OLTP 和 OLAP 分层解耦，通过 CDC 保持实时同步
- 团队有分布式数据库运维能力，或可接受 SelectDB 托管版降低运维成本
以下情况建议评估其他方案：
- 数据规模 <10TB，分析负载不高------PostgreSQL 索引 + 分区 + 只读副本足以满足
- 业务不涉及全文检索和向量检索------纯粹 BI 分析场景可评估更轻量的 ClickHouse 等方案
- 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 社区 交流更多实践。