PostgreSQL 扩展生态全景解析（第五期）：分布式扩展 —— 从分片到存算分离的进化之路 引言：单机 PostgreSQL 的天花板 我们的系列走到了第五期。第一期我们讨论了扩展生态的宏观图景，第二期探了 GIS，第三期探了向量，第四期探了时序。它们回答的问题分别是“在哪里”“像什么”和“何时”。但还有一个更加基础的问题，在前面几期的讨论中悄然浮现—— 当数据量增长到单机存不下时，怎么办？ 想象一个多租户 SaaS 平台，每个租户的数据都在同一张表里。一年后，这张表突破数十亿行。PostgreSQL 的优良设计——MVCC、索引、查询优化器——在这个规模下依然能正常工作，但服务器的 CPU、内存、磁盘 I/O 终究有上限。单机 PostgreSQL 的吞吐量和存储容量有天花板。 这个天花板，正是本期要讨论的问题：分布式扩展。 […]
PostgreSQL 扩展生态全景解析（第四期）：TimescaleDB —— 当 PostgreSQL 拥抱时间之河 引言：时间，数据的第四维度 前三期，我们讨论了 PostgreSQL 如何通过扩展获得三种能力：GIS（理解空间）、全文搜索（理解关键词）、向量检索（理解语义）。本期，我们要探讨的是数据的第四维度——时间。 时间数据无处不在。打开一个 Web 应用的监控面板，曲线图上每一条线都是从“过去”延伸到“现在”的大时间序列。每当用户刷新页面，新数据用写操作推入数据库，下一秒的曲线就有了新的高点。 但问题是：监控面板背后，数据库正在经历什么？ 一台联网汽车每秒产生数千个数据点，一个工业物联网平台一天能积累数亿条记录。几周之后，这张表就膨胀到数十亿行。普通的 PostgreSQL 设计目标是事务处理，索引膨胀、VACUUM 压力、全表扫描——每一个都是在高频时序写入面前最先倒下的短板。 TimescaleDB 敢在
PostgreSQL 扩展生态全景解析（第三期）：pgvector —— 当关系型数据库“理解”语义 引言：从“匹配关键词”到“理解含义” 继续我们的扩展之旅。如果说第二期的 PostGIS 让数据库“看懂”了地图，解决了“我在哪里”的几何空间问题，那么本期的 pgvector 则要回答一个更抽象的问题：“它像什么？” 想象一个电商场景。用户输入“送长辈的礼盒”。普通的关键词搜索如果只匹配商品标题，会漏掉那些标题不含“礼盒”二字却符合“挑选给长辈”这一意图的商品。而一个能“理解”语义意图的系统，则能穿透字面的屏障，在更深处定位到真正的需求。 pgvector 正是在这样的背景下应运而生的。它把文本、图像等信息转化成高维向量（Embedding），让数据库不仅能存和查，还能通过向量运算进行语义相似性搜索。 而 pgvector 真正的变革力量在于——它让这一切在标准 SQL 内就以“原生”方式实现了： CREATE EXTENSION
PostgreSQL 扩展生态全景解析（第二期）：PostGIS —— 把数据库变成 GIS 背后的秘密 引言：当数据库学会“看地图” 回顾上一期，我们提到了一条神奇的 SQL：CREATE EXTENSION postgis;。这条命令就像给数据库装上了一个“地理大脑”，让它突然能计算距离、判断多边形包含关系、规划最优路径。 但这里藏着一个根本性的追问：一个为表格设计的数据库，究竟是怎么变得“懂地理”的？ 不妨做一个思想实验。当一个电商 App 要找出“用户附近 3 公里内的自提点”，普通的数据库会怎么做？它会用经纬度两个字段，对全表逐行计算距离，再排序。百万级数据量，并发一上来，CPU 直接拉满。 而装了 PostGIS
PostgreSQL 扩展生态全景解析（第一期）：为什么 Postgres 是“数据库界的 Linux” 开篇：从一个疑问说起 “PostgreSQL 很强”，这句话在数据库圈子里几乎成为共识。但如果你追问一句它到底强在哪里，答案往往会落到一个词上——扩展性。 不妨做一个思想实验：假如你有一个传统的关系型数据库，里面存着用户订单和商品库存，运行得稳稳当当。这时老板突然说：“我们要做一个打车软件，需要计算两点之间的距离和最优路径。” 你的第一反应可能是：换个数据库？迁移数据？ETL？ 但在 PostgreSQL 的世界里，答案只有一行 SQL： CREATE EXTENSION postgis; 就这么简单。原本普通的订单表旁边，立刻长出了地理空间计算的能力。再后来，老板又说：“我们要做一个 AI 搜索，根据用户的自然语言问题找回最相关的文档。”
PostgreSQL 复制与高可用系列（七）：架构全景与选型决策——从单点到韧性系统 前六期围绕 PostgreSQL 的复制与高可用展开了一次系统性探索：从 WAL 日志的物理本质，到流复制与逻辑复制的协同；从同步/异步的模式权衡，到 PITR 的恢复实践；最后以 Patroni 的生产级部署收束，完成了高可用技术的完整拼图。 作为系列收官之作，第七期将鸟瞰全局：比较主流高可用方案的适用边界，剖析级联复制与读写分离的水平扩展形态，给出业务导向的选型模型，并展望云原生与智能化时代的技术演进方向。最终帮助读者建立起从“能搭”到“会选”再到“懂演进”的完整能力。 一、补充篇：级联复制与读写分离 前六期主要聚焦于主从两层架构。但在实际大型系统中，级联复制和读写分离往往是必须具备的能力，本节系统地补上这两块知识。 1.1 级联复制（Cascading Replication） 定义：备库不仅可以从主库接收 WAL 流，还可以将
PostgreSQL 复制与高可用系列（六）：Patroni生产级高可用集群部署——自动容灾与 K8s 集成 前五期完成了从物理流复制到逻辑复制、从 WAL 内核到 PITR 备份恢复的全链路学习。每一期都在夯实一个核心理念：高可用不仅仅是一句口号，而是由一套环环相扣的技术体系保障的运行韧性。 但前五期的所有知识还存在一个缺口：故障切换需要人工介入。当主库在凌晨三点宕机时，依赖值班工程师执行pg_ctl promote的方式既慢又不安全。第六期将填补这个缺口——全面系统地介绍 Patroni，这款 PostgreSQL 生态中最流行的高可用自动化管理工具。 一、为什么需要 Patroni 1.1 传统方案的痛点 前五期中，我们已经掌握了手动搭建流复制集群的全部技能，包括配置同步/异步模式、修复pg_rewind回切等。然而，仅靠手工运维，会持续面临三个令人头疼的问题： 主库故障时，切换需要人工介入：DBA
PostgreSQL 复制与高可用系列（五）：WAL 内核揭秘与 PITR 备份恢复——把时间掌握在自己手中 前四期我们系统学习了物理复制与逻辑复制的完整知识体系，从单机到主从，从同步到异步，从物理到逻辑。 但必须正视一个现实：复制虽然解决了连续性问题，却并非万能的。当一条 DELETE 语句漏写了 WHERE 条件，主从集群中的所有副本会忠实地复制这份错误，瞬间删除整张表。面对这样的情况，高可用方案往往无能为力——它只能应对硬件故障，而非人为失误。 第五期将深入 WAL 这一数据库的”黑匣子”，系统梳理基于连续归档的备份恢复体系，这是数据安全的最后一道防线，也是每一位数据库工程师必须掌握的核心能力。 一、一个真实的事故与两条不可替代的生命线 事故还原：某企业在生成环境的一次数据迁移过程中，误执行了 TRUNCATE TABLE orders CASCADE，涉及近两年的核心交易数据。幸存的物理备库忠实地重放了这条
PostgreSQL 复制与高可用系列（四）：逻辑复制深度实战——跨版本迁移、数据分发与冲突处理 前三期我们完成了物理流复制从理论到实战的全链路学习，掌握了高可用架构的基石。 但物理复制有一个天然局限：它复制的是整个数据库集群，无法“选择性地同步几张表”，也不能在主备之间做异构同步（比如 12 → 17 跨大版本）。 第四期将聚焦逻辑复制——这张灵活的“手术刀”，为您打开数据同步的全新维度。 一、逻辑复制是什么？ 1.1 定义与定位 逻辑复制是一种基于数据对象的复制标识（通常是主键）来复制数据对象及其更改的方法。这里使用“逻辑”一词来与物理复制（基于块地址和逐字节复制）加以区分——物理复制关注的是磁盘上数据块的变化，而逻辑复制关注的是数据的语义变化（插入、更新、删除）。 核心特点：PostgreSQL 同时支持物理复制和逻辑复制两种机制，两者可以并行运行，不互斥。这给了架构设计极大的灵活性。 1.2 架构：一次 WAL 的两面使用 逻辑复制的架构与物理流复制类似，同样由
PostgreSQL 复制与高可用系列（三）：同步与异步复制工程实践——RPO/RTO 量化与性能权衡 第二期我们亲手搭建了流复制集群，验证了异步与同步两种模式的基本行为。 但生产环境中，“选同步还是异步”从来不是一道非黑即白的选择题——它涉及到业务对数据丢失的容忍度、对写入延迟的敏感度、网络基础设施的可靠性，以及预算与运维成本的综合权衡。 第三期将系统分析同步与异步复制的工程取舍，并给出可量化的决策模型。 一、开篇：一个真实的生产事故 某互联网公司采用 PostgreSQL 异步流复制搭建了主备高可用架构。某日凌晨，主库所在物理机因 SSD 损坏而宕机，系统按预案自动切换到备库。恢复服务后才发现，故障前 5 秒内写入的一笔高价值订单数据永远丢失了——因为该事务的 WAL 记录尚在主库内存中，未传输到备库。 事后分析，RPO 约等于 5 秒。对于该公司的主力业务，RPO