WindowsAzureの2億のエンティティのストアにクエリを実行する必要があります。理想的には、このタスクにはSQLAzureではなくテーブルサービスを使用したいと思います。
ユースケースは次のとおりです。新しいエンティティを含むPOSTは、Web向けAPIから着信します。新しいエンティティを受け入れるかどうかを判断するには、約2億のエンティティにクエリを実行する必要があります。
エンティティの制限が1,000の場合：これはこのタイプのクエリに適用されますか？つまり、一度に1,000をクエリして比較/ビジネスルールを実行する必要がありますか、それとも2億のエンティティすべてを一度にクエリできますか？後者の場合、タイムアウトになると思います。
アイデア？
テーブルストレージに関するShirazのコメントの拡張：テーブルはパーティションに編成され、エンティティは行キーによってインデックス付けされます。したがって、パーティションキーと行キーの組み合わせを使用すると、各行を非常に高速に見つけることができます。秘訣は、特定のアプリケーションに最適なパーティションキーと行キーを選択することです。
上記の例では、電話番号で検索している場合、TelephoneNumberをパーティションキーにすることができます。その電話番号に関連するすべての行を非常に簡単に見つけることができます（ただし、アプリケーションがわからないので、予想される行数はわかりません）。さらに洗練されたものにするために、パーティションキー内にインデックスを作成できる行キーを定義する必要があります。これにより、レコードが存在するかどうかを通知するための非常に高速な応答が得られます。
テーブルストレージ（実際にはAzure Storage一般-テーブル、BLOB、キュー）にはよく知られているSLAがあります。特定のパーティションで1秒あたり最大500のトランザクションを実行できます。上記の例では、特定の電話番号の行のクエリは1つのトランザクションに相当します（返される行が1000を超えない限り、すべての行を表示するには、追加のフェッチが必要です）。行キーを追加して検索を絞り込むと、実際には単一のトランザクションが生成されます）。したがって、新しい行を挿入します。1つのパーティション内で複数の行挿入をバッチ処理し、それらを1つのトランザクションに保存することもできます。
いくつかの優れたラボを含むAzureTableStorageの概要については、プラットフォームトレーニングキットをご覧ください。
テーブル内のトランザクションの詳細については、このmsdnブログ投稿を参照してください。
1000の制限は、クエリから返される行の数であり、クエリされた行の数ではありません。
2億行すべてをWebサーバーにプルして、それらをチェックすることはできません。
秘訣は、レコードを受け入れる必要があるかどうかを確認するために使用できるキーを使用して行を格納することです。