ユニークなシリアル番号の生成

このドキュメントでは、独自の一意の ID を生成する開発者を支援するために、一意のシリアル番号生成スキームを紹介します。

自動増分列

AUTO_INCREMENTは、MySQL プロトコルと互換性のある多くの RDBMS のAUTO_INCREMENT属性です。2 属性を使用すると、データベースはユーザーの介入なしにこの列に値を自動的に割り当てることができます。テーブル内のレコード数が増加すると、この列の値は自動的に増加し、一意であることが保証されます。ほとんどのシナリオでは、 AUTO_INCREMENT列は実際の意味を持たないプロキシ主キーとして使用されます。

AUTO_INCREMENT列の制限は、列が整数型で、割り当てられる値も整数でなければならないことです。アプリケーションで必要なシリアル番号が文字、数字、その他の文字で分割されている場合、ユーザーがAUTO_INCREMENT列を通じてシリアル番号に必要な自動増分番号を取得するのは困難です。

シーケンス

シーケンスは、アプリケーションが増分シーケンス値を生成するために呼び出すことができるデータベースオブジェクトです。アプリケーションは、シーケンス値を柔軟に使用して、1 つ以上のテーブルに値を割り当てることができます。また、アプリケーションは、シーケンス値を使用して、より複雑な処理を行い、テキストと数字の組み合わせを生成することもできます。このアプローチにより、プロキシキーに追跡と分類の意味が与えられます。

シーケンスはTiDB v4.0以降で使用可能です。詳細についてはシーケンスドキュメントを参照してください。

スノーフレークのようなソリューション

Snowflake は Twitter が提案する分散 ID 生成ソリューションです。実装はいくつかありますが、より一般的なのは Baidu のuid-generatorと Meituan のleafです。このセクションではuid-generator例として使用します。

uid-generatorによって生成される 64 ビット ID 構造は次のとおりです。

| sign | delta seconds | worker node id | sequencs |
|------|---------------|----------------|----------|
| 1bit |     28bits    | 22bits         | 13bits   |

符号: 1 ビットの固定長。生成された ID が常に正の数であることを示すために0に固定されます。
デルタ秒: デフォルトでは 28 ビット。現在の時刻は、事前設定された時間基準 (デフォルトは2016-05-20 ) に対する増分値として秒単位で表されます。28 ビットでは、最大約 8.7 年までサポートできます。
ワーカーノード ID: デフォルトでは 22 ビット。マシン ID を表します。通常は、アプリケーションプロセスの開始時に集中 ID ジェネレータから取得されます。一般的な集中 ID ジェネレータには、自動増分列と ZooKeeper があります。デフォルトの割り当てポリシーは、実行時に破棄され、プロセスは再起動時に新しいワーカーノード ID を再取得します。22 ビットでは、最大約 420 万回の起動をサポートできます。
シーケンス: デフォルトでは 13 ビット。1 秒あたりの同時実行シーケンス。13 ビットでは、1 秒あたり 8192 の同時実行シーケンスをサポートできます。

番号割り当てソリューション

番号割り当てソリューションは、データベースから自動増分 ID を一括取得することとして理解できます。このスキームには、各行がシーケンスオブジェクトを表すシーケンス番号生成テーブルが必要です。テーブル定義の例は次のとおりです。

フィールド名	フィールドタイプ	フィールドの説明
`SEQ_NAME`	varchar(128)	異なるアプリケーションを区別するために使用されるシーケンスの名前。
`MAX_ID`	ビッグイント(20)	現在割り当てられているシーケンスの最大値。
`STEP`	整数(11)	割り当てられた各セグメントの長さを示すステップ。

アプリケーションは毎回、設定されたステップでシーケンス番号のセグメントを取得します。同時にデータベースを更新して、割り当てられた現在のシーケンスの最大値を維持します。シーケンス番号の処理と割り当ては、アプリケーションのメモリ内で完了します。シーケンス番号のセグメントが使い果たされると、アプリケーションは新しいシーケンス番号のセグメントを取得し、データベースへの書き込みの負荷を効果的に軽減します。実際には、ステップを調整してデータベースの更新頻度を制御することもできます。

最後に、上記の 2 つのソリューションによって生成された ID は、TiDB テーブルの主キーとして直接使用できるほどランダムではないことに注意してください。実際には、生成された ID に対してビット反転を実行して、よりランダムな新しい ID を取得できます。たとえば、ビット反転を実行すると、ID 00000010100101000001111010011100 00111001011110000010100101000000になり、 11111111111111111111111111111101は10111111111111111111111111111111になります。

助けが必要？

TiDB コミュニティ、またはサポートチケットを作成するについて質問します。