サブデータベースサブテーブルの後、ID主キーをどう扱うか？
業務量が多くなり、データベース内のデータ量が多すぎる場合、サブデータベースとサブテーブルを作成する必要がありますが、サブデータベースとサブテーブルの次に、どのように作成するかという問題が必ず発生します。 IDを生成するには？なぜなら、複数のテーブルに分割した後も、各テーブルの自己インクリメントIDを使用すると、各テーブルが1から累積されることになり、明らかに間違っています。サポートにはグローバルに一意の ID が必要です。したがって、これは実際の運用環境でも考慮する必要がある問題です。グローバル ID ジェネレーターは通常、次の特性を満たす必要があります。
独自性、高可用性、増分性、セキュリティ、高可用性
一般的な主キー ID 生成戦略は次のとおりです。
データベースの自己インクリメントID
原理：
この方法を使用する場合、システムで ID を取得するたびに、ビジネス上の意味を持たないデータをライブラリ内のテーブルに挿入し、データベースで自動インクリメントされる ID を取得する必要があることを意味します。 ID を取得して、対応するサブデータベースとサブテーブルに書き込みます。
このアプローチの長所と短所は次のとおりです。
利点: 非常にシンプルで、整然と増分され、ページングや並べ替えに便利です。
欠点:
a. サブデータベースとサブテーブルの後では、データ テーブルの自動インクリメント ID は簡単に繰り返すことができ、直接使用することはできません (ステップ サイズは設定できますが、制限は明らかです)。
b. 全体的なパフォーマンスのスループットは比較的低いです。分散アプリケーションでデータの一意性を実現するために別のデータベースを設計する場合、事前に生成されたソリューションを使用する場合でも、トランザクションの問題により同時実行性の高いシナリオで単一点のボトルネックが発生する傾向があります。
使用シナリオ: 単一データベース インスタンスのテーブル ID (マスター/スレーブ同期シナリオを含む)、日ごとにカウントされたいくつかのシリアル番号など。
分割テーブルまたはグローバル一意 ID のシナリオでは使用されません。
Redis本番グローバルID
原理：
Redis の INCR/INCRBY 自動インクリメント アトミック操作コマンドを使用すると、生成される ID が一意のシリアル番号であることが保証され、実装方法はデータベースの実装方法と基本的に同じになります。
Redis を使用してグローバル ID を生成する利点と欠点は次のとおりです。
利点: 全体的なスループットはデータベースのスループットよりも高くなります。Redisのスループット性能はデータベースよりも高いため
欠点: Redis インスタンスまたはクラスターがダウンした後、最新の ID 値を取得するのは面倒です。ただし、一意の ID を生成するアルゴリズムを最適化して、この状況を回避できます。
使用シナリオ: コンピューティング シナリオにより適しています。たとえば、ユーザーの訪問数、注文のシリアル番号 (日付 + シリアル番号) などです。
Kaigeおすすめ記事：Redis Combat 9 - グローバルにユニークなID
UUID、GUID生成ID
長所と短所：
長所: 非常に高性能。ローカルで生成され、ネットワークを消費しません。
欠点: UUID が長すぎ、多くのスペースを占有し、主キーとしてのパフォーマンスが低下します。
UUI は順序付けされていないため、B+ ツリー インデックスの書き込み時にランダムな書き込み操作が多すぎます。
使用シナリオ: ファイル名や番号などをランダムに生成したい場合は、UUID の使用を検討できますが、データベースの主キーとして使用する場合は、UUID の使用はお勧めできません。
スノーフレーク アルゴリズム (スノーフレーク)
スノーフレーク アルゴリズムは Twitter から来ており、Scala 言語で実装されています。スノーフレーク アルゴリズムの特徴は、整然としていてユニークであり、高いパフォーマンスと低遅延を必要とします (各クラスターは 1 秒あたり少なくとも 10,000 個のデータを生成し、応答時間は2MS) マルチモード環境(マルチクラスタ、クロスコンピュータルーム)で使用されます。したがって、スノーフレーク アルゴリズムによって取得される ID はセグメントで構成されます。
a. 指定した日付との時差（ミリ秒単位の時差）41桁で69年間使用可能。
b. マシン ID + クラスター ID、10 桁、最大 1024 台のマシンをサポートします。
c. シリアル番号、12 桁。各マシンは、ミリ秒あたり最大 4096 個のシリアル番号を生成できます。
スノーフレーク アルゴリズムの中心となるアイデアは次のとおりです。
配布IDはlong型の番号として固定されており、long型は8バイト、つまり8*8=64ビットを占有する。したがって、スノーフレーク アルゴリズムの形式は次のようになります。
スノーフレーク アルゴリズムはセグメント化されており、各セグメントの意味は次のとおりです。
最初の段落: つまり、最上位ビットは符号ビットです。固定値は 0 で、すべての ID が正の整数であることを示します。
2 番目の段落: 次の 41 ビットはタイムスタンプを識別します。単位はミリ秒です。41 ビットでマークされた数値は、2^41 乗 -1 に対応します。つまり、2 の 41 乗 -1 ミリ秒値を識別できます。成人に換算すると 69 歳になります。
3 番目の段落: 次の 10 桁はマシン ID を識別します。リモート配備の場合はマルチクラスタ構成も可能ですが、オフラインの各場所のコンピュータ室数、クラスタ数、インスタンスIDなどを事前に計画しておく必要があります。これには 5 桁のマシン ID と 5 桁のクラスター ID が含まれており、最大 2^10 のマシンをデプロイできます。つまり1024単位です。
4 番目の段落: 最後の 12 桁はシリアル番号です。同じミリ秒内に生成された異なる ID を記録するために使用されます。12 ビットで表現できる最大の正の整数は 2^12-1=4096 です。つまり、これらの 12 ビットは、4096 を区別するための数値を表すために使用できます。同じミリ秒内に異なる ID。
このアルゴリズムの長所と短所は次のとおりです。
スノーフレーク アルゴリズムの長所と短所:
利点: ミリ秒数が高い位置にあり、自動インクリメント シーケンスが低い位置にあるため、ID 全体が増加傾向を示します。
データベースなどのサードパーティシステムに依存せず、安定性が高く、ID生成のパフォーマンスも非常に高いサービスデプロイメントを使用します。
ビットはそれぞれのビジネス特性に応じて割り当てることができるため、非常に柔軟です。
欠点:
クラスターのクロックに依存しすぎると、マシンのクロックがダイヤルバックされると、重複やサービスの利用不能が発生する可能性があります。
結論
操作についてご質問がある場合は、私の 個人ブログ (www.kaigejava.com)またはWeChat 公開アカウント (Kaige Java)にメッセージを残してご連絡ください。
こんにちは、Kaige Java (kaigejava) です。技術的な記事を共有できることをうれしく思います。皆さんも「Kaige Java」に注目して、すぐに学習してください。一緒にJavaを学びましょう。何かありましたら、カイ兄弟とチャットしに来てください~~~