PostgreSQL与MongoDB对比

PostgreSQL 和 MongoDB 是两种不同类型的数据库系统（关系型 vs. NoSQL），各有其适用场景和优缺点。

1. 数据模型

• PostgreSQL

  • 优点
    • 关系型模型：基于表格结构，支持严格的 Schema 设计，适合结构化数据。
    • 复杂关系：支持 JOIN、外键约束、事务和多表关联查询。
    • 数据类型丰富：支持 JSON、地理空间数据、数组等扩展类型。
  • 缺点
    • 灵活性低：Schema 需预先定义，修改结构可能需迁移数据。

• MongoDB

  • 优点
    • 文档模型：以 BSON（类 JSON）格式存储数据，支持动态 Schema，适合非结构化或半结构化数据。
    • 嵌套数据：可直接存储嵌套对象，避免复杂 JOIN。
  • 缺点
    • 弱关系支持：不支持 JOIN，需通过应用层或冗余数据解决关联查询。

2. 查询能力

• PostgreSQL

  • 优点
    • 强大的 SQL 支持：支持复杂查询、窗口函数、CTE（公共表表达式）等。
    • 全文搜索：内置全文检索功能（如 tsvector）。
  • 缺点
    • 学习曲线：复杂 SQL 需要较高熟练度。

• MongoDB

  • 优点
    • 灵活的查询语法：支持嵌套字段查询、聚合管道（Aggregation Pipeline）。
    • 地理空间查询：原生支持地理位置索引和查询。
  • 缺点
    • 功能限制：复杂查询需依赖聚合框架，语法较 SQL 更晦涩。

3. 扩展性

• PostgreSQL

  • 优点
    • 垂直扩展：通过硬件升级提升性能，适合事务密集型场景。
    • 水平扩展：可通过 Citus 等插件实现分片，但复杂度较高。
  • 缺点
    • 分片支持弱：原生分片功能有限，通常依赖第三方工具。

• MongoDB

  • 优点
    • 原生水平扩展：通过分片（Sharding）轻松扩展集群，适合大数据量和高吞吐场景。
    • 自动负载均衡：数据分布和请求路由由系统自动管理。
  • 缺点
    • 运维复杂度：分片集群需要更多维护工作。

4. 事务与一致性

• PostgreSQL

  • 优点
    • ACID 事务：支持多行、多表事务，适合金融等高一致性场景。
    • 强一致性：默认保证数据的强一致性。

• MongoDB

  • 优点
    • 灵活一致性：支持可调一致性级别（如最终一致性）。
    • 多文档事务：4.0+ 版本支持跨文档 ACID 事务，但性能开销较大。
  • 缺点
    • 事务限制：早期版本无事务支持，现有版本的事务性能低于关系型数据库。

5. 性能

• PostgreSQL

  • 优点
    • 复杂查询高效：优化器成熟，擅长处理复杂 JOIN 和聚合。
    • 写入性能：适合频繁更新和事务场景。
  • 缺点
    • 高并发写入：相比 MongoDB，单节点写入吞吐量可能较低。

• MongoDB

  • 优点
    • 高吞吐读写：内存映射文件机制提升读取速度，适合读多写少场景。
    • 写入速度：默认“非阻塞”写入（可调安全级别）。
  • 缺点
    • JOIN 缺失：关联查询需多次操作，可能影响性能。

6. 适用场景

• PostgreSQL

  • 需要强一致性、复杂事务的应用（如金融系统）。
  • 结构化数据为主，频繁 JOIN 和复杂查询的场景（如 ERP、CRM）。
  • 地理空间数据处理（PostGIS 扩展）。

• MongoDB

  • 快速迭代、Schema 频繁变更的应用（如敏捷开发、内容管理系统）。
  • 非结构化数据存储（如日志、用户行为数据）。
  • 高吞吐读写和水平扩展需求（如物联网、实时分析）。

总结

维度	PostgreSQL	MongoDB
数据模型	结构化，强 Schema	灵活，动态 Schema
扩展性	垂直扩展为主，水平扩展复杂	原生水平扩展
查询能力	复杂 SQL，强关系支持	简单查询高效，嵌套数据友好
一致性	强一致性	最终一致性（可配置为强一致性）
事务	完善的多行事务	多文档事务（4.0+，性能较低）
典型场景	金融、ERP、地理数据	实时分析、日志、内容管理

选择建议：

• 需要严格的事务和复杂查询 → PostgreSQL。
• 数据模型多变或需水平扩展 → MongoDB。

明天记录一下这两天 Samsung 刷机的流程