前幾天在 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
到現在還是一個蠻簡單的解法...
