現在、AzureTableStorage用のアプリケーションを開発しています。そのアプリケーションでは、挿入が比較的少ないテーブル（数千/日）があり、これらのエンティティの主キーは、数十億行の別のテーブルで使用されます。
したがって、小さなテーブルの主キーとして、GUIDの代わりに自動インクリメントされた整数を使用する方法を探しています（多くのストレージを節約し、挿入のスケーラビリティは実際には問題ではないため）。
このトピックについては、 http ：//social.msdn.microsoft.com/Forums/en/windowsazure/thread/6b7d1ece-301b-44f1-85ab-eeb274349797などでいくつかの議論がありました。
ただし、並行性の問題をデバッグして特定するのは非常に難しいため、これを単独で実装するのは少し不快です。したがって、私の質問は、これについて十分にテストされた影響があるかどうかです。
検索でそれを見つけるすべての人にとって、より良い解決策があります。テーブルロックの最小時間は15秒です-それはひどいです。真にスケーラブルなソリューションを作成したい場合は、これを使用しないでください。使用してくださいEtag！
ID用のテーブルに1つのエンティティを作成します（IDなどの名前を付けることもできます）。
1）それを読んでください。
2）インクリメント。
3）InsertOrUpdate WITH ETagが指定されています（読み取りクエリから）。
最後の操作（InsertOrUpdate）が成功すると、新しい一意の自動インクリメントIDが得られます。失敗した場合（HttpStatusCode== 412の例外）、他のクライアントが変更したことを意味します。したがって、もう一度1、2、3を繰り返します。通常の時間は200msRead+InsertOrUpdate未満です。githubにソースがある私のテストユーティリティ。
JoshTwistによるUniqueIdGeneratorクラスを参照してください。
私はまだこれを実装していませんが、それに取り組んでいます...
使用する次のIDをキューにシードし、必要なときにキューからそれらを選択することができます。
キューに追加された最大数の値を含むテーブルを保持する必要があります。大量の整数を使用しないことがわかっている場合は、ワーカーを頻繁に起動させて、キューに整数が含まれていることを確認することができます。また、使用中のintキューを使用して、ワーカーが使用状況を監視できるようにすることもできます。
また、そのワーカーを接続して、コードにIDが必要なときにキューが空の場合（偶然）、ワーカーの仮眠を中断して、できるだけ早くより多くのキーを作成することもできます。
その呼び出しが失敗した場合は、次の方法が必要になります（ワーカーに作業を行うように指示し（ロック）、次にワーカーに次のIDを取得してロックを解除する作業を実行します）
次に、新しい値を使用します。
私が見つけた解決策は、IDの重複を防ぎ、自動インクリメントできるようにすることです。
ブロブをロック（リース）し、それを論理ゲートとして機能させます。
次に、値を読み取ります。
増分値を書き込む
リースを解除する
アプリ/テーブルの値を使用する
次に、そのプロセス中にワーカーの役割がクラッシュした場合、ストアにIDがないだけになります。複製よりも優れている私見。
これは、コードサンプルとSteveMarxによるこのアプローチの詳細です。
GUIDを本当に回避する必要がある場合は、日付/時刻に基づいたものを使用してから、パーティションキーを利用して同時実行のリスクを最小限に抑えることを検討しましたか。
パーティションキーは、ユーザー、年、月、日、時間などによるものであり、行キーは、同時実行性を制御するのに十分短いタイムスパンでの残りの日時である可能性があります。
もちろん、Azureでの日付を犠牲にして、Guidを回避することがこの余分な努力のすべてに本当に価値があるかどうかを自問する必要があります（Guidが正常に機能すると仮定します）。