データベース主キー ID 生成戦略

前書き:

一意のシステム ID は、システム設計時によく遭遇する問題であり、一般的な ID 生成戦略をいくつか紹介します。

##● シーケンス ID

##● UUID

##● GUID

##● COMB

##● Snowflake

最初の自動- IDのインクリメント データベースを分割する必要に応じて、自動インクリメントを前提に異なる開始点を使用しますが、データベースの拡張が必要な​​場合は非常に面倒です。たとえば、最初に特定のシステムのデータベースを設計するとき、データベースには 10 個のテーブルが存在します。その後、各テーブルのコンテンツに対して異なる ID が必要になります。たとえば、最初のテーブルのように、異なる非増加形式を使用できます。は 1、11、21、31 です。 。 。 2 番目のテーブルは 2、12、22、32 です。 。 。 3 番目のテーブルは 3、13、23、33 です。 。 。 10 番目のテーブルは 10、20、30 です。 。 。しかし問題は、ある日、このシステム内の 10 個のテーブルでは十分ではないことがわかり、別のテーブルを追加したい場合、この時点で主キーをどのように割り当てるべきかということです。また、複数のデータベースのデータを結合したい場合でも、この単純なID生成方法では重複する可能性が非常に高いため、ほぼ確実に重複が発生します。明らかに、前の方法のスケーラビリティは低くなります。

自動インクリメント ID と比較すると、UUID は一意の主キーを生成するのに便利です (データ量が非常に多い場合、重複する可能性があります)。ただし、UUID は無秩序な性質があるため、パフォーマンスは自動インクリメント ID や文字列ストレージほど良くなく、ストレージ容量が大きく、クエリ効率が低くなります。重要: uuid を使用する欠点は、クエリ効率が低いことです。

COMB は、UUID と比較して、生成される ID の順序性を高め、挿入とクエリの効率を向上させます。この記事には簡単な分析が含まれています。

Sonwflake は Twitter の主キー生成戦略であり、128 ビット文字列の代わりに 64 ビット長の整数を使用する COMB の改良版と見なされます。 ID の構成: 最初の 0、41 ビットの時間プレフィックス、10 ビットのノード識別子、同時実行を避けるための 12 ビットのシーケンス番号。

パート 1: シーケンス ID

最も一般的な方法は、データベースが独自のシーケンスまたはフィールドを拡張することです。これはデータベースによって維持され、データベースに固有のものです。

利点:

---

シンプルで便利なコード、許容可能なパフォーマンス。

数値 ID は自然にソートされるため、ソートが必要なページングや結果に非常に役立ちます。

欠点:

データベースが異なれば構文と実装も異なるため、データベースの移行中または複数のデータベース バージョンをサポートする場合に処理する必要があります。

単一データベースまたは読み取り/書き込み分離、または 1 つのマスターと複数のスレーブの場合、生成できるマスター データベースは 1 つだけです。単一障害点が発生するリスクがあります。

性能が要件を満たさない場合、拡張は困難です。

複数のシステムを統合する必要がある場合、またはデータ移行が必要な場合は、非常に困難を伴うことになります。

テーブルやデータベースを分割するときに問題が発生します。

最適化計画:

メインライブラリの単一点について、複数のマスターライブラリがある場合、各マスターライブラリに設定される開始番号とステップは異なります。サイズは同じであり、マスターの数にすることができます。

例: Master1 は 1、4、7、10 を生成し、Master2 は 2、5、8、11 を生成し、Master3 は 3、6、9、12 を生成します。これにより、クラスター内で一意の ID が効果的に生成され、ID 生成データベース操作の負荷が大幅に軽減されます。

パート 2: UUID

npm 管理 https://www.npmjs.com/package/uuid 一般的な方法 , 128ビット。これはデータベースまたはプログラムを使用して生成でき、通常はグローバルに一意です。

---

UUID は 128 ビットのグローバルに一意な識別子で、通常は 32 バイトの文字列で表されます。 GUID とも呼ばれる時間と空間の一意性を保証できます。正式名は、UUID - Universally Unique IDentifier、Python では UUID と呼ばれます。

MAC アドレス、タイムスタンプ、名前空間、乱数、擬似乱数によって、生成された ID の一意性が保証されます。

UUID には主に 5 つのアルゴリズム、つまり 5 つの実装方法があります。

(1), uuid1()

——タイムスタンプに基づきます。 MAC アドレス、現在のタイムスタンプ、および乱数から生成されます。グローバルな一意性は保証されますが、MAC を使用するとセキュリティの問題も発生するため、ローカル エリア ネットワークでは MAC の代わりに IP を使用できます。

(2), uuid2()

分散コンピューティング環境 DCE に基づきます (この関数は Python には存在しません)。アルゴリズムは uuid1 と同じですが、タイムスタンプの最初の 4 桁が POSIX UID に置き換えられる点が異なります。この方法は実際にはほとんど使用されません。

(3), uuid3()

名前ベースの MD5 ハッシュ値。これは、名前と名前空間の MD5 ハッシュ値を計算することによって取得され、同じ名前空間内の異なる名前の一意性と、異なる名前空間の一意性が保証されますが、同じ名前空間内の同じ名前は同じ uuid を生成します。

(4), uuid4()

乱数に基づきます。擬似乱数から得られるものには一定の繰り返し確率があり、この確率は計算できます。

(5)、uuid5()

名前ベースの SHA-1 ハッシュ値。アルゴリズムは、セキュア ハッシュ アルゴリズム 1 アルゴリズムが使用されることを除いて、uuid3 と同じです。

利点:

シンプルで便利なコード。

データ移行、システムデータの統合、データベースの変更が発生した場合でも、世界で唯一、冷静に対応できます。

欠点:

並べ替えがないため、傾向が増加することは保証できません。

UUID は文字列を使用して保存されることが多く、クエリ効率は比較的低くなります。

ストレージ容量は比較的大きいため、大規模なデータベースの場合はストレージ量を考慮する必要があります。

送信データ量が多くて読めません。

最適化ソリューション:

UUID が読み取れないという問題を解決するには、UUID to Int64 メソッドを使用できます。

パート 3: GUID

GUID: これは、Microsoft による UUID 標準の実装です。 GUID だけでなく、UUID には他にもさまざまな実装があります。メリット、デメリットはUUIDと同様です。

---

パート 4: COMB

COMB (結合) 型はデータベース固有の設計思想であり、改良された GUID として理解できます。これにより、GUID とシステム時間を組み合わせて、インデックス作成と取得のパフォーマンスが向上します。

---

データベースには COMB 型はありません。これは、Jimmy Nilsson の記事「主キーとしての GUID のコスト」で設計されました。 \

COMB データ型の基本的な設計思想は次のとおりです。 UniqueIdentifier データはその不規則性によりインデックス効率が低く、システムのパフォーマンスに影響を与えるため、データ型の一意性を維持できるでしょうか。 UniqueIdentifier を組み合わせて使用​​しますか? 最初の 10 バイトが使用され、最後の 6 バイトは GUID が生成された時刻 (DateTime) を表すために使用されます。このようにして、時刻情報と UniqueIdentifier を組み合わせて、順序性を維持しながら順序性を高めます。 UniqueIdentifier の一意性により、インデックスの効率が向上します。

利点:

UUID の乱れの問題を解決し、主キー生成メソッドに Comb アルゴリズム (GUID/タイムスタンプの組み合わせ) を提供します。 GUID の 10 バイトを予約し、残りの 6 バイトを使用して GUID が生成された時刻 (DateTime) を表します。

パフォーマンスは UUID よりも優れています。

パート 5: Twitter のスノーフレーク アルゴリズム

Snowflake は Twitter のオープンソースの分散 ID 生成アルゴリズムであり、結果は長い ID になります。中心となるアイデアは、ミリ秒数として 41 ビット、マシン ID として 10 ビット (5 ビットがデータセンター、5 ビットがマシン ID)、ミリ秒以内のシリアル番号として 12 ビット (つまり、各ノードが4096 ID を生成します）、最後には符号ビットがあり、常に 0 になります。スノーフレーク アルゴリズムは、独自のプロジェクトのニーズに応じて変更できます。たとえば、アルゴリズムに必要なビット数を調整するために、将来のデータ センターの数、各データ センターのマシンの数、統一ミリ秒内に発生する可能性のある同時実行数を推定します。

---

利点:

データベースに依存せず、柔軟で便利で、データベースよりもパフォーマンスが優れています。

ID は単一マシン上で時間に応じて増加します。

欠点:

は単一マシン上で増分されますが、分散環境のため、各マシンのクロックを完全に同期することができず、場合によっては同期できない場合があります。グローバルな増分が達成されない状況。

6.

を使用します。 これは非常に便利です。

npm install uuid --save

では、使用してみましょう。

  const uuidv1 = require(‘uuid/v1‘);
  console.log(‘随机uuid字符串‘, uuidv1());

このようにして、uuid 文字列を出力できます。毎回違うんです。

以上がデータベース主キー ID 生成戦略の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。