資料庫主鍵 ID 生成策略

程式設計師的貓發表於2019-07-30
資料庫

前言：　

　系統唯一ID是我們在設計一個系統的時候常常會遇見的問題，下面介紹一些常見的ID生成策略。

  • Sequence ID
  • UUID
  • GUID
  • COMB
  • Snowflake

　　最開始的自增ID為了實現分庫分別的需求，會在自增的前提下，使用不同起點，但需要做資料庫擴充時，極其麻煩。 比如剛開始時，我們設計某個系統的資料庫時，這個資料庫中會有10個表，那麼我們對於每個表的內容都需要不同的ID我們就可以使用不同不長自增的形式，比如，第一張表的是1、11、21、31。。。 第二張表是2、12、22、32。。。 第三張表是3、13、23、33。。。 第十張表就是10、20、30。。。 但是這樣的問題就是，如果有一天我發現這個系統的10張表已經不夠用了，我想要再新增一張表，那麼這時的主鍵應該怎麼分配呢？ 另外，如果對於多個資料庫的資料希望合併，但是對於這種簡單的生成ID方式，重複的可能性很大，所以幾乎一定會發生重複這種情況。 顯然，如果使用之前的方法的可擴充套件性會比較差。

　　相比自增ID，UUID生成唯一主鍵更加方便（資料量非常大的情況下，存在重複的可能），但由於UUID的無序性，效能不如自增ID，字串儲存，儲存空間大，查詢效率低。關鍵：使用uuid的缺點是查詢效率低啊！

　　COMB相對於UUID，增加了生成ID的有序性，插入與查詢效率都有所提高。 這篇文章有簡單的分析。

COMB資料型別的基本設計思路是這樣的：既然UniqueIdentifier資料因毫無規律可言造成索引效率低下，影響了系統的效能，那麼我們能不能透過組合的方式，保留UniqueIdentifier的前10個位元組，用後6個位元組表示GUID生成的時間（DateTime），這樣我們將時間資訊與UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時增加了有序性

　**　Sonwflake是Twitter主鍵生成策略，可以看做是COMB的一種改進**，用64位的長整型代替128位的字串。ID構成：第一位0 + 41位的時間字首 + 10位的節點標識 + 12位的sequence避免併發的數字。

第一部分：Sequence ID

　　資料庫自增長序列或欄位，最常見的方式。由資料庫維護，資料庫唯一。

優點：

  1. 簡單，程式碼方便，效能可以接受。
  2. 數字ID天然排序，對分頁或者需要排序的結果很有幫助。

缺點：

  1. 不同資料庫語法和實現不同，資料庫遷移的時候或多資料庫版本支援的時候需要處理。
  2. 在單個資料庫或讀寫分離或一主多從的情況下，只有一個主庫可以生成。有單點故障的風險。
  3. 在效能達不到要求的情況下，比較難於擴充套件。
  4. 如果遇見多個系統需要合併或者涉及到資料遷移會相當痛苦。
  5. 分表分庫的時候會有麻煩。

最佳化方案：

　　　針對主庫單點，如果有多個Master庫，則每個Master庫設定的起始數字不一樣，步長一樣，可以是Master的個數。

比如：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。這樣就可以有效生成叢集中的唯一ID，也可以大大降低ID生成資料庫操作的負載。

第二部分：UUID

　　npm 管理 www.npmjs.com/package/uuid

　 　常見的方式,128位。可以利用資料庫也可以利用程式生成，一般來說全球唯一。

　　UUID是128位的全域性唯一識別符號，通常由32位元組的字串表示。它可以保證時間和空間的唯一性，也稱為GUID，全稱為：UUID ―― Universally Unique IDentifier，Python 中叫 UUID。

　　它透過MAC地址、時間戳、名稱空間、隨機數、偽隨機數來保證生成ID的唯一性。

　　 UUID主要有五個演算法，也就是五種方法來實現。

（1）、 uuid1()

――基於時間戳。由MAC地址、當前時間戳、隨機數生成。可以保證全球範圍內的唯一性，但MAC的使用同時帶來安全性問題，區域網中可以使用IP來代替MAC。

（2）、uuid2()

――基於分散式計算環境DCE（Python中沒有這個函式）。演算法與uuid1相同，不同的是把時間戳的前4位置換為POSIX的UID。實際中很少用到該方法。

(3)、uuid3()

――基於名字的MD5雜湊值。透過計算名字和名稱空間的MD5雜湊值得到，保證了同一名稱空間中不同名字的唯一性，和不同名稱空間的唯一性，但同一名稱空間的同一名字生成相同的uuid。

（4）、uuid4()

――基於隨機數。由偽隨機數得到，有一定的重複機率，該機率可以計算出來。

（5）、uuid5()

――基於名字的SHA-1雜湊值。演算法與uuid3相同，不同的是使用 Secure Hash Algorithm 1 演算法。

優點：

  1. 簡單，程式碼方便。
  2. 全球唯一，在遇見資料遷移，系統資料合併，或者資料庫變更等情況下，可以從容應對。

缺點：

  1. 沒有排序，無法保證趨勢遞增。
  2. UUID往往是使用字串儲存，查詢的效率比較低。
  3. 儲存空間比較大，如果是海量資料庫，就需要考慮儲存量的問題。
  4. 傳輸資料量大
  5. 不可讀。

最佳化方案：

  1. 為了解決UUID不可讀，可以使用UUID to Int64的方法。

第三部分： GUID

GUID：是微軟對UUID這個標準的實現。UUID還有其它各種實現，不止GUID一種。優缺點同UUID。

第四部分： COMB

　 COMB（combine）型是資料庫特有的一種設計思想，可以理解為一種改進的GUID，它透過組合GUID和系統時間，以使其在索引和檢索事有更優的效能。

　　資料庫中沒有COMB型別，它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中設計出來的。
　　COMB資料型別的基本設計思路是這樣的：既然UniqueIdentifier資料因毫無規律可言造成索引效率低下，影響了系統的效能，那麼我們能不能透過組合的方式，保留UniqueIdentifier的前10個位元組，用後6個位元組表示GUID生成的時間（DateTime），這樣我們將時間資訊與UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時增加了有序性，以此來提高索引效率。

優點：

  1. 解決UUID無序的問題，在其主鍵生成方式中提供了Comb演算法(combined guid/timestamp)。保留GUID的10個位元組，用另6個位元組表示GUID生成的時間(DateTime)。
  2. 效能優於UUID。

第五部分： Twitter的snowflake演算法

　snowflake是Twitter開源的分散式ID生成演算法，結果是一個long型的ID。其核心思想是：使用41bit作為毫秒數，10bit作為機器的ID（5個bit是資料中心，5個bit的機器ID），12bit作為毫秒內的流水號（意味著每個節點在每毫秒可以產生 4096 個 ID），最後還有一個符號位，永遠是0。snowflake演算法可以根據自身專案的需要進行一定的修改。比如估算未來的資料中心個數，每個資料中心的機器數以及統一毫秒可以能的併發數來調整在演算法中所需要的bit數。

優點：

  1. 不依賴於資料庫，靈活方便，且效能優於資料庫。
  2. ID按照時間在單機上是遞增的。

缺點：

  1. 在單機上是遞增的，但是由於涉及到分散式環境，每臺機器上的時鐘不可能完全同步，也許有時候也會出現不是全域性遞增的情況。

六、使用

這個使用起來是真的方便：

npm install uuid --save

然後就可以使用啦！

  const uuidv1 = require(‘uuid/v1‘);
  console.log(‘隨機uuid字串‘, uuidv1());

這樣，我們就可以列印出來uuid字串了。 每次的都不一樣。

本作品採用《CC 協議》，轉載必須註明作者和本文連結
你還差得遠吶！

相關文章