白話文解說 ULID (Universally Unique Alphabetically Sortable Identifier)

先前提到蠻多人會使用 UUID 作為確保唯一性的 Id 欄位使用,不過 UUID 的隨機性會有不可排序的問題,舉個例子來說,上一秒還產生 47 開頭的 UUID 字串,下一秒就可能變成 36 開頭的字串,這就導致像 MySQL 這類的資料庫需要更新多個 pages ,資料量大的時候,新增資料將會出現效率問題。

也由於這個問題,所以有人提出 ULID ,讓 ULID 的產生會按照字典順序排序(Lexicographically Sortable),除了可排序的特點之外, ULID 還有幾項特點:

  1. 相容 UUID ,都使用 128 bits
  2. 支援 millisecond 級別的唯一 Id (如果你的使用量已經超過 millisecond 級別,ULID 就不適合使用)
  3. URL safe 的編碼方式(方便用於 URL),編碼後只需要 26 個字元,比起 UUID 的 36 字元更短
  4. 不分大小寫

雖然 ULID 看起來似乎比起 UUID 更好一些,不過 ULID 前面 48 bits 代表時間戳記(timestamp),所以有可能會導致一些安全性的問題,例如只要知道時間戳記,那麼有心人士只要去產生剩下的 80 bits 就能夠猜中某些 Id ⋯⋯。

另外一個問題是 ULID 不像 UUID 有 RFC 標準,只有一份 GitHub Spec 可供參考,每個套件是否正確實作 ULID 的規格,就看套件作者的良心或者要自己多做些測試才知道⋯⋯。

不過不管使用什麼方法產生 Id ,最好要了解一下方法差異才比較好挑選適合自己應用程式的 Id 。(以前沒查不知道 UUID 作為 PK 會有一些問題⋯⋯😭)

Facebook Threads X

對抗久坐職業傷害

研究指出每天增加 2 小時坐著的時間,會增加大腸癌、心臟疾病、肺癌的風險,也造成肩頸、腰背疼痛等常見問題。

然而對抗這些問題,卻只需要工作時定期休息跟伸展身體即可!

你想輕鬆改變現狀嗎?試試看我們的 PomodoRoll 番茄鐘吧! PomodoRoll 番茄鐘會根據你所設定的專注時間,定期建議你 1 項辦公族適用的伸展運動,幫助你打敗久坐所帶來的傷害!

贊助我們的創作

看完這篇文章了嗎? 休息一下,喝杯咖啡吧!

如果你覺得 MyApollo 有讓你獲得實用的資訊,希望能看到更多的技術分享,邀請你贊助我們一杯咖啡,讓我們有更多的動力與精力繼續提供高品質的文章,感謝你的支持!