重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

一意のシリアル番号の生成

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

自動インクリメント列

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

AUTO_INCREMENT列の制限は、列が整数型である必要があり、それらに割り当てられる値が整数である必要があることです。アプリケーションに必要なシリアル番号が文字、数字、その他の文字でスライスされている場合、ユーザーはAUTO_INCREMENT列からシリアル番号に必要な自動インクリメント番号を取得するのが困難です。

順序

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

シーケンスは、TiDBv4.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ビットの固定長。 0に固定され、生成されたIDが常に正の数であることを示します。
  • デルタ秒:デフォルトで28ビット。現在の時刻。事前設定されたタイムベース(デフォルトは2016-05-20 )を基準にした秒単位の増分値として表示されます。 28ビットは最大約8。7年をサポートできます。
  • ワーカーノードID:デフォルトで22ビット。マシンIDを表します。通常、アプリケーションプロセスの開始時に集中IDジェネレーターから取得されます。一般的な集中型IDジェネレーターには、自動インクリメント列とZooKeeperが含まれます。デフォルトの割り当てポリシーはdiscard-as-you-goであり、プロセスは再起動時に新しいワーカーノードIDを再取得します。 22ビットは最大約420万の開始をサポートできます。
  • シーケンス:デフォルトで13ビット。 1秒あたりの同時実行のシーケンス。 13ビットは、1秒あたり8192の同時シーケンスをサポートできます。

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

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

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

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

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