uuid – Gea-Suan Lin's BLOG

在 PostgreSQL 裡，當 UUID 當作 Primary Key 時要怎麼處理

繼續清 tab，在「PostgreSQL and UUID as Primary Key (maciejwalkowiak.com)」這邊看到的，原文是討論 PostgreSQL 要怎麼處理 PK 是 UUID 的情況：「PostgreSQL and UUID as primary key」。

文章開頭作者就說了，這篇不是要戰 PK 要不要用 UUID，而是已經決定要用了 (i.e. 通常不是你決定的)，在接手以後要怎麼用比較好：

Considering the size of UUID it is questionable if it is a right choice, but often it is not up to us to decide.

This article does not focus on "if UUID is the right format for a key", but how to use UUID as a primary key with PostgreSQL efficiently.

首先是 PostgreSQL 從 8.3 版 (2008 年) 就支援 UUID 的資料型態了，這點從 release note 可以看到：「PostgreSQL 8.3.0」，所以要當 PK 的話沒什麼道理不考慮他。

用 UUID 的空間上就是 128-bit data (16 bytes)，相比於 TEXT 會省蠻多的，尤其 PK 常常會被其他表格 reference 到 (像是 foreign key) 會在其他表格也省下來：

Table that uses text is 54% larger and the index size 85% larger.

第二點則是考慮到 UUID 本身的特性，以前的 UUID 因為是亂數生成的 (通常會用 UUIDv4)，對寫入 B-tree 類的資料結構不是很有效率，改用 UUIDv7 (差不多是這兩年陸陸續續發展出來的規格) 會得益於與 timestamp 有關，對 B-tree 寫入的效率會好很多：

Random UUIDs are not a good fit for a B-tree indexes - and B-tree index is the only available index type for a primary key.

B-tree indexes work the best with ordered values - like auto-incremented or time sorted columns.

UUID - even though always looks similar - comes in multiple variants. Java's UUID.randomUUID() - returns UUID v4 - which is a pseudo-random value. For us the more interesting one is UUID v7 - which produces time-sorted values. It means that each time new UUID v7 is generated, a greater value it has. And that makes it a good fit for B-Tree index.

作者的測試可以看到寫入速度與 UUIDv4 相比比快不少：

BUT we can clearly see, that inserting UUID v7 is ~2x faster and inserting regular UUID v4.

總結來說，當 PK 已經決定是 UUID 後，主要就是這兩個重點可以注意的，當然 Hacker News 上更熱鬧的是兩派人馬在吵要用 integer 類的 SERIAL/BIGSERIAL 還是用 UUID，那又是另外一個話題了...

如果早個二十年前對 memory size 斤斤計較的情況下，答案鐵定是 integer 類的，但年代不同了...？

UUID 的 UX

在「The UX of UUIDs (unkey.dev)」這邊看到的紋章，原文在「The UX of UUIDs」。

裡面有不少是有幫助的建議，像是第一個建議是把 UUID 裡面的 - 拿掉，這樣對於 copy 比較方便 (畢竟大多數人應該是 copy UUID，不會是念出來？)。

第二個建議是加上 prefix，這點不一定侷限在 UUID，只要是 token 上面都很適合。這個在不少系統上應該都有看過，像是 GitHub 的 token，或是 AWS 的 token 都算是這類。

文章裡面沒有提到，但這個建議也可以幫助你在 CI 上設定 regex，擋下把 secret token 寫進去的行為。

第三個提到用 base58，一方面是減少長度，另外一方面是想要避免 1IiLl 與 0Oo 的問題，這點我覺得還好... 既然都是 copy & paste 了，我覺得拿 base62 (i.e. 大小寫加上數字) 不錯，這避免特殊字元無法選擇到，也就是文章裡面第一個建議。

第四個建議是建議重新思考 range，因為 UUID 的 128-bit range 很大，但不是所有應用都需要用到這麼大的範圍確保 collision-free (於是可以當 primary key)。

這點讓我想到 X (Twitter) 當初發表的 Snowflake ID，在 Twitter 這種規模下 64-bit range 也已經夠用。

後面的文章內容就是在推銷自家東西，我就... 跳過了。

2019 年 Percona 對 UUID 當作 Primary Key 的看法

前陣子的「為資料庫提案新的 UUID 格式」這邊提到了有人提案要增加新的 UUID 格式，Percona 的老大 Peter Zaitsev 在 Twitter 上貼了「UUIDs are Popular, but Bad for Performance — Let’s Discuss」這篇在 2019 年時他們家的文章，題到了 MySQL 使用 UUID 當作 Primary Key 的事情：

UUIDs are Popular, but Bad for Performance — Let’s Discuss
https://t.co/2ulSGPB77L

— Peter Zaitsev (@PeterZaitsev) August 21, 2021

要注意的是這篇文章沒有要從頭解釋 UUID 對於 Primary Key 的壞處，如果你想要先了解的話，在這篇文章的開頭給了一堆其他文章的連結，裡面就有討論過了。

這篇主要是在討論，如果硬要用 UUID 當 Primary Key 時，可以有什麼方法降低對 InnoDB 的衝擊，剛好回應最近的提案。

開頭還是先花了一些篇幅大概講一下 UUID 的種類，然後在「What is so Wrong with UUID Values?」這邊提到了字串比較的差異，如果 UUID 是到最後一碼才不同的話 (這邊是跑 df878007-80da-11e9-93dd-00163e000002 與 df878007-80da-11e9-93dd-00163e000003 與比較一億次)：

1 row in set (27.67 sec)

但如果是一開始就不同的話 (這邊是選擇 df878007-80da-11e9-93dd-00163e000002 與 ef878007-80da-11e9-93dd-00163e000003) 會快很多：

1 row in set (2.45 sec)

但如果與數字相比的話 (這邊是 2=3 這樣的條件去比)：

1 row in set (0.96 sec)

可以看數字在這邊的優勢，另外也是在說明，如果你用的是 time-based ordering 的 UUID，要考慮會遇到這個可能會發生的效能問題。

再來是玩 UUID 的三種不同的儲存方式對於寫入效能的差異，分別是 CHAR(36) (32 bytes 的 hex 加上四個 -)、base64 (用 CHAR(22) 存) 與 BINARY(16)，可以看出來 BINARY(16) 因為佔用空間比較小的關係，是可以高速寫入持續最久的，再來是 base64，最差的是 CHAR(36)：

後面給了兩個 workaround，第一個算是定義了另外一種產生 128 bits 的方式，第二個則是想辦法把 UUID 對應到數字。

這在 MySQL 的環境裡面算是被討論的很久的主題了。(我猜在 PostgreSQL 應該也是，不過 PostgreSQL 的社群沒跟那麼久...)

為資料庫提案新的 UUID 格式

前幾天在 Hacker News Daily 上看到的東西，今年四月的時候有人針對資料庫提案新的 UUID 格式：「New UUID Formats – IETF Draft (ietf.org)」。

在 draft 開頭有說明這個提案的目標：

This document presents new time-based UUID formats which are suited for use as a database key.

A common case for modern applications is to create a unique identifier for use as a primary key in a database table. This identifier usually implements an embedded timestamp that is sortable using the monotonic creation time in the most significant bits. In addition the identifier is highly collision resistant, difficult to guess, and provides minimal security attack surfaces. None of the existing UUID versions, including UUIDv1, fulfill each of these requirements in the most efficient possible way. This document is a proposal to update [RFC4122] with three new UUID versions that address these concerns, each with different trade-offs.

另外在 Hacker News 上有人整理出來，可以直接理解提案所提出的新格式是什麼：

A somewhat oversimplified summary of the new UUID formats:

UUID6: a timestamp with a weird epoch and 100 ns precision like in UUID1, but in a big-endian order that sorts naturally by time, plus some random bits instead of a predictable MAC address.

UUID7: like UUID6, but uses normal Unix timestamps and allows more timestamp precision.

UUID8: like UUID7, but relaxes requirements on where the timestamp is coming from. Want to use a custom epoch or NTP timestamps or something? UUID8 allows it for the sake of flexibility and future-proofing, but the downside is that there's no standard way to parse the time from one of these -- the time source could be anything monotonic.

這在不同的 storage engine 上面會有不同的討論，這邊先討論 MySQL 系列的 InnoDB，至於 PostgreSQL 的 engine 以及其他資料庫系統，就另外讓更熟悉的人討論了。

InnoDB 採用了 clustered index (可以參考「Database index」這邊的說明)，也就是資料本體是以某種定義的大小順序存放。

在 InnoDB 裡面則是用 primary key 的順序來存放資料 (沒有指定 primary key 時會有 fallback 行為)，其他的 unique key 與 index key 則是指到 primary key，所以你可以看到 primary key 的大小也會影響到其他的 index key。

所以 128 bits 的 UUID 在大型的 MySQL ecosystem 實在不怎麼受歡迎，在 2010 年的時候 Flickr 與 Twitter 都有發表過 ticket system：「Ticket Servers: Distributed Unique Primary Keys on the Cheap」、「Announcing Snowflake」，兩個系統有不同的需求，但都是產生 64 bits 的 unique id。

其中 Flickr 的系統算是很簡單的，沒有要保證時間順序 (i.e. 先取的號碼一定比較小，以及後取的號碼一定比較大)，就用兩台 MySQL 跑 active-active 架構，然後錯開產生的值：

TicketServer1:
auto-increment-increment = 2
auto-increment-offset = 1

TicketServer2:
auto-increment-increment = 2
auto-increment-offset = 2

到現在還是一個蠻簡單的解法...

莎士比亞風格的 UUID

UUID 是個長 128 bits 的數字，轉成 16 進位也有 32 個字要記，對於人類記憶來說不太友善。

前幾天在 Hacker News 上看到的東西，把這 128 bits 的資訊轉成類莎士比亞的句子，相比前面 32 個 16 進位的數字來說好記不少：「uuid-readable」。

Generate Easy to Remember, Readable UUIDs, that are Shakespearean and Grammatically Correct Sentences

給的輸出範例包括了：

Loren Chariot Addy the Titbit of Cholame questioned Cele Garth Alda and 16 windy frogs

Drucill Hubert Lewse the Comer of Avera rejoices Fiann Craggy Florie and 5 hard trouts

Jacquette Brandt John the Pectus of Barnsdall doubted Glenn Gay Gregg and 12 noisy stoats

我不覺得有變簡單啊 XDDD 也許對於英文母語的人來說會簡單一些... 吧？

InnoDB 對 Primary Key 的選擇

前幾天 Ant 在「淺入淺出 MySQL & PostgreSQL」剛好有提到，結果 Percona 這兩天也丟出了這個題目，不過這邊討論的是空間的問題：「Illustrating Primary Key models in InnoDB and their impact on disk usage」。

一樣的作法，Primary Key 的選擇有三種：

INT + AUTO_INCREMENT
BINARY(16) (Ordered UUID)
CHAR(36) (Random UUID)

用的是 Jeremy Cole 的 space-lsn-age-illustrate 畫出 LSN 的值 (InnoDB 的 Log Sequence Number，由於嚴格遞增，可以藉由這個值知道每個 page 最新被修改的時間)：

I then used the powerful tool innodb_space’s function space-lsn-age-illustrate (from Jeremy Cole’s innodb_ruby project) to plot the LSN (InnoDB’s Log Sequence Number, an always-incrementing value) pages from each table that uses the different Primary Keys via ASCII colour (so hot, right? Thanks Jeremy!!).

測試是 INSERT-only 的 case，雖然不太能理解為什麼要用 CHAR(36) 存 UUID，而非與 BINARY(16)，但可以看出一些 pattern。

有順序的 INT + AUTO_INCREMENT 與 BINARY(16) (Ordered UUID) 都可以看出層次 (一直往後寫)，而且也看得出來 BINARY(16) 比 INT 大了不少：