MS PDCのプレゼンテーションから、PartitionKeyが複数のサーバー間でテーブルの負荷分散に使用されていることは理解していますが、PartitionKeyが単一のサーバー内でインデックスとして使用されているかどうかについては誰もアドバイスしていないようです。
同様に、PartitionKeyとRowKeyを指定すると優れたパフォーマンスが得られると誰もが言うでしょうが、PartitionKey内のパフォーマンスを向上させるためにRowKeyが使用されているかどうかは誰にもわかりません。
質問を組み立てるのに役立ついくつかのサンプルクエリを次に示します。テーブル全体に1億行が含まれていると仮定します。
これが私の質問です：
ATSでは、PartitionKeyはインデックスではなく、分布ルックアップとして使用されます。ATSでの作業のレベルから、PartitionKeyと「サーバー」/ノードが1：1の関係を共有することを検討してください。 （舞台裏ではこれは真実ではありませんが、同じ物理/仮想ノードに存在するPartitionKeysの最適化などの概念は、Azureのコンシューマーが処理する必要があるものからいくつかのレベルで抽象化されています。これらの詳細は純粋に全体の内部にあります。 AzureインフラストラクチャとATSの場合は、それが最適であると想定するのが最善です...別名「心配しないでください」）
DBMSとATSのコンテキストでは、RowKeyは、類似したノード全体でデータを見つけるのに役立つという点で、「インデックス」に最も近いものです。質問の1つに直接答えるために、RowKeyはPartitionKey内のインデックスです。
ただし、ボックスの外に少し踏み出すと、 PartitionKeyを使用すると、従来のインデックスの考え方に近いパフォーマンスを得ることができますが、これは、データがATSノード全体に分散されるという性質があるためです。最初にPartitionKeyに、次にRowKeyにレイアウトを最適化する必要があります。（別名、キー入力可能な値が1つしかない場合は、それをPartKeyにします）
一般的に、クエリは最も効率的なものから最も効率的でないものの順に実行されます。
ルックアップは正しいノードに到達し、次にパーティション上のインデックス付きプロップに到達するためです
適切なノードに到達しますが、ATSequviに到達するためです。全表スキャンの
パーティションスキャンを実行してから、テーブルスキャンを実行する必要があるためです。
それで、あなたの直接の質問に
私はこれが答えられるとは思わない。その主観的（すなわち、「何が速いのか？」）。常にQuery2よりも遅くなりますが、10行の場合、「速度」がミリ秒になる可能性があります。
（同様のテーマ）クエリ1よりも高速になります。クエリ2を実行できるときはいつでも、
したがって、その説明と質問から、本当の答えは、アーキテクトがATSをどのように使用するかにかかっています。
データセット（現在の成長と予想される成長の両方）に基づいて、パーティションに到達し、行に到達できるようにするための適切なスキームを決定する必要があります。ルックアップがどのように行われるかを知っていると、どのパスが十分に速くそこに到達するか、より多くの部分、より少ない行-対より少ない部分、より多くの行などについて論理的な決定を下すことができます
テーブルは（PartitionKey、RowKey）によってインデックス付けされます。同じパーティションキーを持つ行は、同じパーティションから提供されることが保証されています。異なるPartitionKeyを持つ行は、同じパーティション上にある場合とない場合があります。したがって、パーティションに10行しかないことをどのように知ることができるかわかりません。
PartitionKey = "123"の行が10行しかない場合、最初のクエリは「高速」になります。2番目のクエリは「高速」になります。
＃1の場合、10個のエンティティの高速スキャンです。
＃2の場合、そのRowKey範囲にエンティティがいくつあるかによって異なります。（パーティションキーと行キーの範囲を指定すると、その範囲内のエンティティのみに対してインデックス付きクエリが実行されます。）いくつあるかはわかりませんが、例として、10個ある場合はその場合、＃1と同じパフォーマンスになるはずです。
どちらも比較的高速である必要があります。
クエリ1は、単一のパーティション内でフルスキャン（ATS用語の範囲スキャン）を実行する必要がありますが、これは10個のエンティティを反復処理することを意味します。
クエリ2でも範囲スキャンが実行されますが、パーティション内のインデックスとしてRowKeyを使用するため、高速である必要があります。
各クエリのパフォーマンスへの影響と、最適なキーを定義する方法を含む非常に詳細なブログ投稿を取得できます：http: //blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how -to-get-most-out-of-windows-azure-tables.aspx
テイラーの答えに加えて、ここで説明するように、類似のステートメントが範囲クエリにも当てはまります。
つまり、Azure Table Storageは、パーティションキーと範囲キーの2つの部分からなる1つのインデックスをこの順序で持つと考えることができます。
WASの論文が書かれてから変わったかもしれないと思いますが、それを読めば結論を出すことができます。
たとえば、パーティションをノード/物理サーバー間で移動できます。単一のパーティションよりも拡張性の高いパーティションが多数ある場合。巨大なパーティションが1つある場合は、単一のパーティションのスループットによって制限されます。
多くの小さなパーティション（範囲内で連続）を単一のノード/物理サーバーに移動できることに注意してください。パーティションが論理的に密接にグループ化されている（つまりソートされている）場合は、パーティション間でのスキャンを遅くする必要はありません。
提供されている2000req/ secを超える量を処理するためにキーをパーティション分割する必要がある場合は、パーティションキーを複数のパーティションに分割する方法を考え出す必要があります。それ以外の場合は問題ありません。
ああ、あなたは単一のパーティションキー内でのみエンティティグループトランザクションを実行できます。これは設計に影響を与える可能性があります。
要約すると：
これらはあなたがあなた自身に尋ねる必要がある2つの質問です。