生成唯一ID,為什么 NanoID 會(huì)取代 UUID?

UUID[1] 是軟件開(kāi)發(fā)中最常用的通用標(biāo)識(shí)符之一。然而,在過(guò)去幾年中,其他替代品挑戰(zhàn)了它的存在。
其中,NanoID 是取代 UUID 的主要競(jìng)爭(zhēng)對(duì)手之一。
因此,在本文中,我將討論 NanoID 的功能、它的亮點(diǎn)以及它的局限性,以便您更好地了解何時(shí)使用它。
了解 NanoID 及其用法
對(duì)于 JavaScript,生成 UUID 或 NanoID 非常簡(jiǎn)單,他們都有 NPM 包來(lái)幫助你。
你所需要做的就是用 npm i nanoid 命令安裝NanoID NPM庫(kù),并在你的項(xiàng)目中使用它。
import { nanoid } from 'nanoid';
model.id = nanoid();
你知道NanoID每周有超過(guò)11,754K的NPM下載量,并且比UUID快60%嗎?
此外,NanoID比UUID年輕近7年,而且它在GitHub上的星級(jí)已經(jīng)超過(guò)了UUID。
下圖顯示了這兩個(gè)的npm趨勢(shì)比較,我們可以看到NanoID的上升趨勢(shì),而UUID的進(jìn)展平平。

我希望這些數(shù)字已經(jīng)說(shuō)服了你去嘗試NanoID。
然而,這兩者之間的主要區(qū)別很簡(jiǎn)單。
由于 NanoID 使用比 UUID 更大的字母表,因此較短的 ID 可以用于與較長(zhǎng)的 UUID 相同的目的。
1.NanoID 的大小只有 108 個(gè)字節(jié)
與 UUID 不同,NanoID 的大小要小 4.5 倍,并且沒(méi)有任何依賴(lài)關(guān)系。
大小減少直接影響數(shù)據(jù)的大小。例如,使用 NanoID 的對(duì)象小而緊湊,用于數(shù)據(jù)傳輸和存儲(chǔ)。隨著應(yīng)用程序的增長(zhǎng),這些數(shù)字變得可見(jiàn)。
2.更安全
在大多數(shù)隨機(jī)生成器中,它們使用不安全的 Math.random()。但是,NanoID 使用更安全的 crypto module 和 Web Crypto API。
此外,NanoID 在 ID 生成器的實(shí)現(xiàn)過(guò)程中使用了自己的稱(chēng)為統(tǒng)一算法的算法,而不是使用 random % alphabet。
3.它快速而緊湊
NanoID比UUID快60%。與UUID的36個(gè)字符不同,NanoID只有21個(gè)字符。
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz-
此外,NanoID 支持 14 種不同的編程語(yǔ)言,它們是
C#, C++, Clojure and ClojureScript, Crystal, Dart & Flutter, Deno, Go, Elixir, Haskell, Janet, Java, Nim, Perl, PHP, Python with dictionaries, Ruby , Rust, Swift
4.兼容性
它還支持 PouchDB、CouchDB WebWorkers、Rollup 以及 React 和 Reach-Native 等庫(kù)。
你可以通過(guò)使用 npx nanoid 在終端獲得一個(gè)唯一的ID,唯一的先決條件是要安裝NodeJS。

此外,你也可以在Redux toolkit[2]內(nèi)找到NanoID,并將其用于其他使用情況,如下所示。
import { nanoid } from ‘@reduxjs/toolkit’
console.log(nanoid()) //‘dgPXxUz_6fWIQBD8XmiSy’
5.自定義字母
NanoID 的另一個(gè)現(xiàn)有功能是它允許開(kāi)發(fā)人員使用自定義字母表。您可以更改文字或 id 的大小,如下所示:
import { customAlphabet } from 'nanoid';
const nanoid = customAlphabet('ABCDEF1234567890', 12);
model.id = nanoid();
在上面的示例中,我將自定義字母表定義為 ABCDEF1234567890,并將 Id 的大小定義為 12。
6.沒(méi)有第三方依賴(lài)
由于 NanoID 不依賴(lài)任何第三方依賴(lài),隨著時(shí)間的推移,它變得更加穩(wěn)定自治。
從長(zhǎng)遠(yuǎn)來(lái)看,這有利于優(yōu)化bundle的大小,使其不容易出現(xiàn)依賴(lài)關(guān)系帶來(lái)的問(wèn)題。
局限性和未來(lái)重點(diǎn)
根據(jù) StackOverflow 中的許多專(zhuān)家意見(jiàn),使用 NanoID 沒(méi)有明顯的缺點(diǎn)或限制。
非人類(lèi)可讀性是許多開(kāi)發(fā)者認(rèn)為NanoID的主要缺點(diǎn),因?yàn)樗拐{(diào)試更加困難。但是,與UUID相比,NanoID要短得多,可讀性強(qiáng)。
另外,如果你使用 NanoID 作為表的主鍵,如果你使用相同的列作為聚集索引也會(huì)出現(xiàn)問(wèn)題,這是因?yàn)?NanoID 不是連續(xù)的。
在未來(lái)...
NanoID 正逐漸成為最流行的 JavaScript 唯一 id 生成器,大多數(shù)開(kāi)發(fā)人員更喜歡選擇它而不是 UUID。

以上基準(zhǔn)測(cè)試顯示了NanoID與其他主要id生成器相比的性能。
在使用其默認(rèn)字母表時(shí),它每秒可生成超過(guò)220萬(wàn)個(gè)獨(dú)特的ID,在使用自定義字母表時(shí),每秒可生成超過(guò)180萬(wàn)個(gè)獨(dú)特的ID。
根據(jù)我使用 UUID 和 NanoID 的經(jīng)驗(yàn),考慮到它的小尺寸、URL 友好性、安全性和速度,我建議在任何未來(lái)的項(xiàng)目中使用 NanoID 而不是 UUID。
因此,我邀請(qǐng)你在你的下一個(gè)項(xiàng)目中嘗試使用NanoID,并在評(píng)論區(qū)與其他人分享你的想法。
原文:https://blog.bitsrc.io/why-is-nanoid-replacing-uuid-1b5100e62ed2
作者:Charuka Herath
參考資料
UUID: https://en.wikipedia.org/wiki/Universally_unique_identifier
[2]Redux toolkit: https://redux-toolkit.js.org/api/other-exports
