一意の部品番号をプロビジョニングするためのシンプルで堅牢なソリューションを探しています。GUID を使用してさまざまなクライアント (デスクトップ、電話など) からの要求を識別し、要求 GUID の挿入日時に基づいて PN を順番に割り当てることを考えていました。
質問: SQL Azure は使用するのに適したサービスですか? これに対する標準的なアプローチはありますか?
ありがとう。
一意の部品番号をプロビジョニングするためのシンプルで堅牢なソリューションを探しています。GUID を使用してさまざまなクライアント (デスクトップ、電話など) からの要求を識別し、要求 GUID の挿入日時に基づいて PN を順番に割り当てることを考えていました。
質問: SQL Azure は使用するのに適したサービスですか? これに対する標準的なアプローチはありますか?
ありがとう。
これは「クラウド上」であることとはほとんど関係がなく、一般的な分散コンピューティングの問題です。
あなたの質問にはあなたの要件を完全に理解するのに十分な情報がありませんが、私が収集しているのは、部品番号を要求するサービスの消費者に一意の番号を割り当てる必要があるということです.
最初に考えられるのは、GUID は数値 (128 ビット長) であるということです。部品番号を割り当てる必要があるときはいつでも GUID を生成できませんか? 必要に応じて、数十億の部品番号を扱っていない限り、ハッシュ衝突のリスクが非常に少ない状態で、GUID を unsigned long にハッシュすることができます (このタイプのアプリケーションでは、City Hash が私のお気に入りの 64 ビット ハッシュです)。 . 32 ビットの数値にハッシュしたいという衝動に駆られた場合は、誕生日問題を見てください。ハッシュの衝突は、32 ビットだけで考えているよりもはるかに頻繁に発生します。
連番を割り当てる必要がある場合は、処理にシリアル化ポイントを導入する必要があります。個々の部品番号の要求をカウントし、次に大きい番号を割り当てるサービス (DB テーブルの ID 列である可能性があります) が必要になります。
一般的に小さい番号が必要であるが、必ずしも連続している必要がない場合は、そのような要求を処理する可能性のある各サーバーが独自の範囲の番号を管理できるようにすることができます (たとえば、特定のサーバーが 1000 個の部品番号のブロックを「チェックアウト」することができます)。中央サービスからそれらを割り当て、それらが使い果たされるまで割り当ててから、番号の新しいブロックを「チェックアウト」します)。複数のサーバーが異なる速度で番号を割り当てる可能性があるため、これは現在割り当てられているすべての番号が連続していることを保証するものではありません。また、アプリケーションのクラッシュを適切に管理しないと、チェックアウトされたが完全に割り当てられていない番号ブロックの一部が「失われる」可能性があります。
あなたはこれを見たいと思うかもしれません: SnowMaker – 一意の ID ジェネレーター