一、技术分类概览
这 7 款技术可以按核心用途分为四大阵营：
- OLTP 事务型：MySQL 和 PostgreSQL 是老牌选手，主要处理交易、订单、用户数据等需要强一致性的场景。想象一下你在淘宝下单、微信转账，背后都是这类数据库在支撑。
- OLAP 分析型：ClickHouse、Doris、DuckDB 专为数据分析设计，擅长处理海量数据的聚合查询。比如你要分析一年的用户行为日志，用它们可能只要几秒，而 MySQL 可能要跑半小时。
- HTAP 混合负载：TiDB 是新生代代表，一套系统同时搞定事务和分析。适合数据量太大（超过 1TB）需要水平扩展，但又不想改代码的场景。
- 数据同步工具：FlinkCDC 不是数据库，而是数据搬运工，负责把数据库的变更实时同步到其他系统，构建实时数仓的核心组件。
1.1 OLTP 阵营：MySQL vs PostgreSQL
MySQL：互联网公司的首选
MySQL 从 1995 年诞生至今，已经成为全球最流行的开源数据库。它的核心优势是简单、快速、可靠。仅需 512MB 内存即可运行，同时读性能表现优异，十分适配读多写少的 Web 应用场景；其主从复制机制成熟，读写分离方案完善，且拥有庞大的社区生态，问题排查与解决十分便捷。
Facebook、YouTube、Uber 等知名企业均广泛应用 MySQL，分别用于支撑海量用户数据存储、视频元数据与评论管理、订单及司机调度等业务，该数据库也非常适合快速迭代的创业公司、电商平台、内容管理系统以及追求快速上手的技术团队使用。
PostgreSQL：功能最强大的开源数据库
PostgreSQL 被誉为“世界上最先进的开源数据库”，以功能丰富、标准兼容、扩展性强为核心优势，支持复杂查询、窗口函数、CTE 等高级 SQL 特性，拥有原生带索引的 JSONB 类型可兼顾关系型与 NoSQL 场景，搭配 PostGIS 插件能实现强大的地理空间查询，同时凭借完善的 MVCC 并发控制有效减少读写冲突。
Instagram、Reddit、Apple 等企业均在关键业务中采用 PostgreSQL，分别用于支撑亿级用户关系与标签、帖子评论投票系统及 iCloud 数据一致性服务，十分适合复杂查询、地理信息系统、需 JSON 文档存储以及对 SQL 标准要求较高的项目场景。
Q&A 思考 🤔
Q -> 那既然 PG 对 NoSql 的兼容性更好，那么对比 MySql + Redis 和 PgSql + Redis 有什么差异？PgSql 会更胜一筹吗？
A -> 总结一句口诀：MySql 轻量通用快，Pg 复杂功能强，Redis 缓存扛高量。 MySQL 与 Redis 搭配是业界最主流的组合，核心用于读多写少的常规 Web 应用，MySQL 负责轻量、稳定、简单的持久化数据存储，Redis 承担高速缓存，二者组合简单高效；而 PostgreSQL 与 Redis 组合则更适合复杂查询、地理空间、JSON 存储等高级场景，功能更强但使用成本略高，两种组合与 Redis 的协作模式完全一致，仅数据库本身的功能和适用场景存在差异。
1.2 OLAP 阵营：ClickHouse vs Doris vs DuckDB
ClickHouse：单表查询性能之王
ClickHouse 是俄罗斯 Yandex 公司开源的列式数据库，以极致的单表查询性能为核心优势，采用列式存储与向量化执行，可实现亿级数据秒级查询返回，数据压缩率高且能有效节省存储空间，虽支持实时写入但更适配批量导入，不过因其使用自定义 SQL 方言，存在一定学习成本；
- 建表必须指定引擎（最典型）
-- ClickHouse 独有
CREATE TABLE user_log (
id UInt64,
name String
) ENGINE = MergeTree() -- 必须写，PG/MySQL 不需要ORDER BY id;
- 聚合查询必须带所有分组字段（和标准 SQL 不同）
-- 标准 SQL 可以
SELECT name, COUNT(*) FROM log GROUP BY name;
-- ClickHouse 要求更严格，必须明确分组所有非聚合列
SELECT name, COUNT(*) FROM log GROUP BY name;
SELECT name, age, COUNT(*) FROM log GROUP BY name, age; -- 必须这样
- 自带超级聚合函数
-- ClickHouse 独有
uniqExact(user_id) -- 精确去重
groupArray(name) -- 分组转数组
sumIf(price, status=1) -- 带条件聚合
- INSERT 批量写法不一样
-- 标准
SQLINSERT INTO t VALUES (1),(2),(3);
-- ClickHouse 支持超高速批量插入
INSERT INTO t VALUES (1),(2),(3),(4),(5)...(100000);
- 不支持事务、不支持常规 UPDATE/DELETE
-- 标准 SQL 支持
BEGIN; UPDATE ...; COMMIT;-- ClickHouse 不支持标准事务，更新删除用特殊语法
ALTER TABLE ... DELETE WHERE ...; -- 轻量删除
Cloudflare、Uber 及腾讯游戏等企业均将其应用于海量数据处理场景，分别用于安全日志与流量数据分析、行程数据监控、用户行为日志分析等，可支撑万亿级数据的高效查询，十分适合日志分析、用户行为追踪、监控指标聚合以及单表大数据量查询等场景。
Doris：易用的 MPP 数据仓库
Doris 是由百度开源并捐赠给 Apache 的 MPP 分析型数据库，主打易用性与高效的多表关联能力，它兼容 MySQL 协议，可直接使用 MySQL 客户端工具连接，采用 FE+BE 架构，部署与运维相对简便，不仅多表关联性能出色，还支持高并发查询与实时数据更新导入；
小米、美团、京东等企业均广泛应用 Doris，分别用于搭建数据仓库、商家运营分析看板、供应链与库存管理等场景，浩瀚深度也于 2025 年从 ClickHouse 迁移至 Doris，用以支撑单表 13PB 海量数据及全国多地区生产环境运行，十分适用于数据仓库建设、多维报表统计、需要复杂多表关联的分析，以及对查询并发要求较高的业务场景。
FE+BE 架构：
用户发 SQL → FE（Frontend 前端节点） 接收、解析、规划任务 → 把任务分给多个 BE 去查数据、算结果 → BE（Backend（后端节点）） 算完把结果返回给 FE → FE 汇总后返回给你。架构只有 FE + BE 两种角色，没有第三方依赖（不用额外搭 Zookeeper 之类复杂组件）扩缩容直接加节点就行，自动均衡，对新手非常友好
DuckDB：嵌入式分析利器
DuckDB 被誉为分析领域的 SQLite，主打零配置、嵌入式与 Python 友好特性，采用单文件存储模式，无需部署独立数据库服务，能与 Python、Pandas 无缝集成，同时凭借列式存储实现远超 SQLite 的数据分析性能，非常适合本地数据分析与 ETL 中间处理；
它被广泛用于数据科学团队替代 Pandas+CSV 工作流、ETL 开发的数据转换中间层，以及无需启动服务的本地开发测试场景，完美适配 Jupyter 数据分析、本地原型验证、小型数据集分析等轻量化使用需求。
DuckDB = 嵌入式轻量分析库，本地数据分析神器，不用搭服务，开箱即用。
Q&A 思考 🤔
Q -> 看到这里，相信不少细心的朋友发现，为啥事务性数据库都是行存储，分析型数据库都是列存储，二者是否有关联？ A -> 行存管交易，列存做统计。（什么意思？让我来给你讲解） 事务数据库（MySQL/PG）：频繁改一行、查整行 → 行存最快 按 “一行一行” 存数据在磁盘上是这样排的：
1,张三,25,8000 → 2,李四,30,12000 → 3,王五,28,10000 优点： 要查一整行信息很快（比如打开用户详情页） 缺点： 只想查 salary（举例） 一列，也要把整行都读出来，很慢 大数据量统计（求和、平均）效率低
> **分析数据库（CK/Doris/DuckDB）：只算几列、算海量数据 → 列存最快**
> **按 “一列一列” 存**数据在磁盘上是这样排的：
> plaintext
> ```
id: 1,2,3
name: 张三,李四,王五
age: 25,30,28
salary:8000,12000,10000
**优点**：
只查某一列，**只读那一列**，速度极快
统计 sum、avg、count 超级快
相同类型数据挤在一起，**压缩率极高**
**缺点**：
查整行数据不如行存储快
所以映射到实际业务中结论也十分明显了： 事务型数据库： 改一行、读一行，只需要读一小块连续数据，速度极快，锁也小，事务好做 分析型数据库：
- 只需要读你要的那几列，不用读无关数据
- 同类型数据放一起，压缩极强
- 统计计算时，CPU 可以批量处理，速度爆炸 如果反过来呢： 行存变列存：你改一行，要去每一列的文件里分别改，相当于跑好几个地方改数据，又慢又难保证事务一致性。 列存变行存：查 sum (money) 也要把整行所有字段都读一遍，海量数据下直接慢到卡死。
1.3 HTAP 阵营：TiDB
TiDB 是 PingCAP 研发的分布式数据库，作为分布式数据库领域的主流方案，核心优势是水平扩展与高度兼容 MySQL。它完全兼容 MySQL 协议，业务改造量极低，支持数据自动分片，可随业务规模平滑扩容，还能提供强一致性分布式事务，满足金融级可靠性要求，并通过_ _TiFlash 列存引擎兼具实时分析能力。
美团、拼多多、中国银联等企业均大规模使用 TiDB，分别支撑百亿级支付与订单交易、营销活动与实时报表、交易流水与风控系统等关键业务，适用于数据量突破单机瓶颈、需要水平扩展又尽量不改业务代码，且同时兼顾在线交易与实时分析的 HTAP 混合负载场景。
1.4 数据同步：FlinkCDC
FlinkCDC 是基于 Apache Flink 的变更数据捕获工具，主要用于构建实时数据管道。它支持 MySQL、PostgreSQL、Oracle、MongoDB 等多种数据源，能够实现全量与增量一体化同步，并通过 Exactly-Once 语义保障数据不丢失、不重复，还可与 Kafka、Doris、ClickHouse 等下游系统无缝对接。
阿里巴巴、字节跳动、Shopee 等企业均通过 FlinkCDC 实现实时数据处理，分别用于实时数仓构建、多数据源汇聚至分析库、订单数据实时归档等场景，适用于数据库到数仓的实时同步、多数据源整合以及对延迟要求达到秒级的数据更新业务。
二、资源占用与成本
从资源消耗角度看，这 7 款技术可以分为三个梯队：
- 轻量级：DuckDB（128MB 即可）、MySQL（512MB 可运行）、PostgreSQL（1GB 推荐）
- 中量级：FlinkCDC（依赖 Flink 集群，2GB 起步）、Doris（4GB 起步）、ClickHouse（4GB 起步）
- 重量级：TiDB（PD+TiKV+TiDB 三组件，8GB 起步，生产环境建议 16GB+）
小团队或成本敏感的项目，优先考虑轻量级选项；数据量大了再考虑迁移到分布式方案。
三、选型决策建议
一个好的选型决策，往往是一个公司的根基。
第一步：看数据量
- 1000 万记录以内：MySQL 或 PostgreSQL 足够
- 1000 万到 10 亿：考虑分库分表或 TiDB
- 10 亿以上：TiDB、ClickHouse、Doris 等分布式方案
第二步：看场景
- 事务处理为主：MySQL、PostgreSQL、TiDB
- 分析查询为主：ClickHouse、Doris、DuckDB
- 混合负载：TiDB、PostgreSQL+ 分析库
第三步：看团队
- 团队熟悉 MySQL：优先 MySQL 生态
- 需要复杂查询：PostgreSQL 更合适
- 数据科学团队：DuckDB+Python 是绝配
第四步：看成本
- 机器成本：TiDB > ClickHouse > Doris > PG > MySQL > DuckDB
- 运维成本：TiDB（需要专业团队）> ClickHouse > Doris > PG > MySQL
四、典型架构模式
对于不同类型的企业，都提供了适合自身的一套方案。
4.1 初创公司（数据量 <1000 万）
MySQL/PostgreSQL（主从复制）
├─ 主库：读写
└─ 从库：备份 + 报表查询
成本：单台 4 核 8G 服务器即可 代表：早期创业公司、内部系统
4.2 成长型企业（数据量 1000 万 -10 亿）
MySQL（分库分表）+ Redis（缓存）
├─ ShardingSphere/MyCat 分片
├─ Redis 缓存热点数据
└─ 定时同步到 ClickHouse 做分析
成本：3-5 台服务器 代表：中型电商、SaaS 服务商
4.3 大型企业（数据量 >10 亿）
TiDB/分布式数据库
├─ 自动分片，透明扩展
├─ TiFlash 提供实时分析
└─ FlinkCDC 同步到数据仓库
成本：10+ 台服务器，专业 DBA 团队 代表：美团（支付交易 +HTAP 实时分析，T+0 数据传输）、拼多多、金融机构
4.4 实时数仓架构
业务数据库 → FlinkCDC → Kafka → Doris/ClickHouse
↓
MySQL/PG BI 报表/数据分析
代表：阿里巴巴、字节跳动、京东
五、迁移路径建议
随着业务的增大，往往需要转型，这里提供几条迁移建议，对于每个场景提供最合适的方案，确保数据不丢失，成本稳定。
从小到大的平滑演进：
- MySQL → 分库分表：使用 ShardingSphere，代码改动小
- MySQL → TiDB：兼容 MySQL 协议，几乎不用改代码
- MySQL → ClickHouse：需要重构查询逻辑，适合分析场景
- 本地分析 → DuckDB：零成本迁移，SQL 兼容 PostgreSQL
迁移成本排序（从低到高）： TiDB < DuckDB < 分库分表 < Doris < ClickHouse
结语
数据库选型没有银弹，只有最适合。小项目别过度设计，大项目别为了省钱硬扛。参考同规模公司的技术选型，往往比自己研究更靠谱。
记住这六条黄金法则：
别过度设计、场景优先、考虑团队能力、成本意识、预留扩展空间、参考大厂实践。
本文链接：
未经作者授权禁止转载！