PostgreSQL 引入 UUIDv7

UUID (Universally Unique IDentifier) 在 RFC4122 中定义,占用 16 字节空间,为方便阅读,通常将其表示为由-分隔的五组十六进制字符串。 -- PostgreSQL 13 增加了内置生成随机 UUID 的方法 postgres=# select gen_random_uuid(); gen_random_uuid -------------------------------------- e6e12d78-8b1b-4c5c-90d2-e07dcbdbee73 (1 row) RFC4122 定义了 5 个不同版本的 UUID,这些版本之间的区别在于生成 UUID 所需的输入和输出的位结构,当人们讨论 UUID 时,几乎总是指 UUIDv4: 其结构中的第 7 个字节的高四位为版本号 0b0100, 第 9 个字节的高两位总是为 0b10,其余 122 位为随机值。因此无论用 SQL 还是命令行工具 uuidgen 生成的 UUID,其在上图中第一个橘色的位置始终为 4,第二个橘色的位置为 8, 9, a, b 中的一个。 contrib 下的 uuid-ossp extension 提供了生成五个版本 UUID 的函数。 UUIDv4 存在的问题 当用 UUIDv4 作为主键时,如果大量写入随机的 UUID 值,会导致 B-tree 更多的页面分裂,较低的 filling factor,大量的页面碎片(Fragmentation),占用更多的存储空间。当索引数据大于内存时,缓存命中率也会逐渐降低。由于写入分散,大量页面需要在 Checkpoint 之后写 FPI,进而导致 WAL 的写入放大,WAL 写入量的增加又会更频繁地触发 Checkpoint,又导致更多的 FPI 写入操作 🥺...

December 9, 2023 · 3 min · 592 words · pg-x

Aurora Limitless Database Related Resources

AWS re:Invent 2023 发布了 Aurora Limitless Database,看起来类似 Citus,但其底层依赖 AWS 长久依赖的技术积淀,比如分布式事务使用了类似 Spanner True Time 的 EC2 TimeSync Service,又如利用 Caspian 来动态解决不同 shard 间的数据偏移。但其技术细节不对外公布,这里收集一些公开资料来学习其内部架构。AWS 真的是把 Serverless 做到了极致 👍🏻。 AWS re:Invent 2023 - Monday Night Live Keynote with Peter DeSantis AWS re:Invent 2023 - Achieving scale with Amazon Aurora Limitless Database Join the preview of Amazon Aurora Limitless Database Hacker News

December 2, 2023 · 1 min · 57 words · pg-x

Postgresql Jsonb Cheatsheet

Source: https://aiven.io/developer/postgresql-jsonb-cheatsheet

December 2, 2023 · 1 min · 2 words · pg-x

PG Coin —— 给开发者最好的礼物

从 9.0 开始,PostgreSQL 基金会为每个发布版本创作一个 Release Artwork,从版本 12 开始,PostgreSQL 基金会把这个 Artwork 制作成 challenge coin 送给该版本的所有贡献者留作纪念。 今年的艺术品名称是 a baker making cloud cakes with jays on (pun) the apron,即一个穿着印有松鸟围裙的面包师傅制作云朵蛋糕。 PostgreSQL 选择大象作为 Logo 是因为 “elephants can remember”,所以每个 Artwork 也都以大象为主题。 对于一个开源项目,这种文化非常值得赞扬。通过向贡献者赠送一个小而用心的礼物,让他们感受到强烈的归属感。这种举动表达了对他们的感谢,同时也激励他们继续为项目做出贡献。

December 1, 2023 · 1 min · 36 words · pg-x

PostgreSQL 为什么不提供 SHOW CREATE TABLE ?

I know it seems dumb, but postgres really needs to add the simple developer experience stuff like: SHOW CREATE TABLE; SHOW TABLES; SHOW DATABASES; SHOW PROCESSLIST; CockroachDB added these aliases ages ago. 如上是 Hacker News 今年 5 月的一个帖子,相信 PostgreSQL 的用户都知道,PostgreSQL has its own way!!! 是的,我们用 slash commands,并且热衷这种简洁的方式: MySQL PG show create table t; \d+ t show tables; \d show tables like "%test%" \dt public.*test* show databases; \l show processlist; SELECT * from pg_stat_activity; 不过 slash commands 只能在 psql 中使用,psql 将相应的命令转换成对应的 SQL 查询发送到 server 端处理。大多情况下,这种方式能满足用户的需求,但也有例外,比如:...

November 26, 2023 · 1 min · 177 words · pg-x

PostgreSQL 的多进程架构有何优势?

PostgreSQL 的多进程架构相对于多线程架构有什么优势?如果你认同 “一个查询的后端进程崩溃不会影响其它连接的后端进程,从而提高了系统稳定性” 是其中一个优势,那请继续看下去 🐘。 postmaster 状态机 postmaster 作为 PostgreSQL 的主进程,在启动时负责创建共享内存和信号量。然而,它自身几乎不直接操作这些资源(当然也有例外,如 PMSignalState),这样的设计使得 postmaster 逻辑更简单、更可靠。当后端进程崩溃时,postmaster 通过重置共享内存和信号量来恢复系统的正常运行。 当 postmaster 接收到客户端请求时,它会立即派生(fork)一个子进程。子进程负责对请求进行权限验证,如果验证成功,则成为一个后端进程,这种设计保证了客户端请求的高效处理。 postmaster 负责启动一系列子进程,包括辅助(Auxilary)进程和普通(Normal)后端进程,其中 startup 进程跟 postmaster 紧密合作来保证数据库的一致性,它调用 StartupXLOG 执行数据库恢复的流程(本文不展开 recovery 的流程)。 postmaster 被实现为一个状态机,父子进程之间通过信号(signal)进行交互,如下是 postmaster 的状态图: postmaster 启动后初始状态为 PM_INIT,完成一些初始化工作后,启动 startup 进程,postmaster 进入 PM_STARTUP 状态 如果 startup 进程完成其工作并正常退出(OS 给 postmaster 发送 SIGCHLD 信号),postmaster 进入 PM_RUN 状态 startup 进程在进行到可以开始 archive recovery 时,给 postmaster 发信号并在共享内存标记 PMSIGNAL_RECOVERY_STARTED,postmaster 处理后进入 PM_RECOVERY 状态 startup 持续重放 wal 日志,如果开启了 Hot Standby,当达到一致状态后,会标记 PMSIGNAL_BEGIN_HOT_STANDBY,postmaster 进入 PM_HOT_STANDBY 状态 postmaster 在 PM_RUN 和 PM_HOT_STANDBY 状态都可以接收请求连接,因此这里把两个状态放在了一起 当有后端进程异常退出后,postmaster 进入 PM_WAIT_BACKENDS 状态,并调用 HandleChildCrash 来通知其它进程退出 所有进程退出后,postmaster 进入 PM_NO_CHILDREN 状态,然后重建共享内存和信号量并启动 startup 进程,postmaster 状态改为 PM_STARTUP 可以看出,一个后端进程的异常退出会影响其它子进程。一个简单的验证方法是使用 kill -9 去杀死一个查询的后端进程,并查看其它后端进程的 pid 是否改变,参考 KILL -9 EXPLAINED FOR POSTGRESQL。...

November 18, 2023 · 2 min · 225 words · pg-x

为什么 PostgreSQL 能代替 MongoDB?

在进行技术选型时,需要考虑众多因素,如功能、性能、可靠性、成本效益、社区支持和团队技术能力等,然而,影响最终决定的关键因素的往往是团队 Leader 的技术品味,这也能解释为什么阿里偏爱 Java,而字节跳动更倾向 Go、Rust 等新兴语言。技术本身无好坏之分,根据实际业务问题选择适当的技术方案是关键。 本文旨在为读者提供一种新的选择,而非论证 PostgreSQL 比 MongoDB 更优秀。 MongoDB 因其灵活的 “Schema-less”(无模式)特性而著名。“Schema-less” 意味着 MongoDB 不要求严格定义数据的结构和字段(使用 BSON 格式存储数据),允许在同一集合中存储具有不同结构的文档,这为开发人员提供了更大的灵活性,能够轻松地适应数据模型的变化和演进。 PostgreSQL 提供的 JSONB 类型可用于存储和处理 JSON 数据,包括嵌套的对象、数组和基本数据类型。因此,PostgreSQL 具备 MongoDB 存储 document 的能力。 PostgreSQL 对 JSON 的支持 我们来了解一下 PostgreSQL 支持 JSON 特性的时间线(统计到版本 14): - PG 9.2 Introduction of JSON (JSON text; no indexes) -- 2012/9/10 - PG 9.4 Introduction of JSONB (binary format; indexes) -- 2014/12/18 - PG 9.5 jsonb_set(), jsonb_object(), jsonb_build_object(), jsonb_build_array, jsonb_agg, || operator etc....

November 11, 2023 · 4 min · 730 words · pg-x