6

テーブルスキャンを強制されないように、Azure Table Storage（ATS）のRowKeyまたはPartitionKey以外に対してクエリを実行しないように警告します。しばらくの間、これは私を麻痺させて、正確に正しいPKとRKを考え出し、他の何かを照会する必要があるときに他のテーブルに疑似セカンダリインデックスを作成しようとしました。

ただし、適切と思われる場合は、SQLServerでテーブルスキャンを実行するのが一般的です。

したがって、問題は、Azureテーブルをどのくらいの速度でテーブルスキャンできるかということです。これはエンティティ/秒で一定ですか、それともレコードサイズなどに依存しますか。レスポンシブアプリケーションが必要な場合、テーブルスキャンにはレコードが多すぎるという目安はありますか？

4

4 に答える 4

7

テーブルスキャンの問題は、パーティションの境界を越えることに関係しています。保証されるパフォーマンスのレベルは、パーティションレベルで明示的に設定されます。したがって、全表スキャンを実行すると、a）あまり効率的ではなく、b）パフォーマンスが保証されません。これは、パーティション自体が別々のストレージノードに設定されており、クロスパーティションスキャンを実行すると、大量のリソースを消費する可能性があるためです（複数のノードを同時に拘束する）。

これらの境界を越えると、継続トークンも発生し、結果を取得するためにストレージへの追加のラウンドトリップが必要になると思います。その結果、パフォーマンスが低下し、トランザクション数（およびその後のコスト）が増加します。

交差しているパーティション/ノードの数がかなり少ない場合は、問題に気付かない可能性があります。

しかし、これについて私を引用しないでください。私はAzureStorageの専門家ではありません。それは実際、私が最も知識が少ないAzureの領域です。：P

于 2011-01-28T20:57:23.817 に答える
0

I think Brent is 100% on the money, but if you still feel you want to try it, I can only suggest to run some tests to find out yourself. Try include the partitionKey in your queries to prevent crossing partitions because at the end of the day that's the performance killer.

于 2011-01-31T11:06:50.993 に答える
0

Azureテーブルは、テーブルスキャン用に最適化されていません。テーブルのスキャンは、長時間実行されるバックグラウンドジョブでは許容できる場合がありますが、迅速な対応が必要な場合はスキャンしません。妥当なサイズのテーブルでは、クエリがパーティションの境界に到達するか、1kの結果を取得するときに、継続トークンを処理する必要があります。

Azureストレージチームには、スケーラビリティの目標を説明するすばらしい投稿があります。単一のテーブルパーティションのスループット目標は500エンティティ/秒です。ストレージアカウントの全体的な目標は、5,000トランザクション/秒です。

于 2011-01-31T23:02:57.830 に答える
0

答えはページ付けです。top_size-最大数の結果または結果のレコード-を継続トークンnext_partition_keyと組み合わせて使用​​します。next_row_keyこれにより、パフォーマンスに大きな違いが生じます。1つは、結果が単一のパーティションから得られる可能性が統計的に高いことです。明白な結果は、セットが行継続キーではなく、パーティション継続キーによってグループ化されていることを示しています。

つまり、UIまたはシステム出力についても考慮する必要があります。最大50の結果を10から20を超えて返すことを気にしないでください。ユーザーはおそらくこれ以上利用したり調べたりすることはありません。

ばかげているように聞こえます。「犬」をGoogleで検索すると、検索で返されるアイテムは10個だけであることがわかります。もういや。わざわざ「続行」を押すと、次のレコードが利用できます。調査によると、その最初のページを超えて冒険するユーザーはほとんどいません。

（キー値のselectサブセットを返す）は違いを生む可能性があります。たとえば、select="PartitionKey,RowKey"または'Name'必要な最小値を使用します。

「これらの境界を越えると、継続トークンも発生し、結果を取得するためにストレージへの追加のラウンドトリップが必要になると思います。これにより、パフォーマンスが低下し、トランザクション数（およびその後のコスト）が増加します。 。」

...少し間違っています。継続トークンが使用されるのは、境界を越えるためではなく、紺碧のテーブルで1000を超える結果が許可されないためです。したがって、2つの継続トークンが次のセットに使用されます。デフォルトのtop_sizeは基本的に1000です。

ご覧いただけるように、azurepythonapiからのクエリエンティティの説明を以下に示します。他はほとんど同じです。

  '''
  Get entities in a table; includes the $filter and $select options. 

  table_name: Table to query.
  filter: 
     Optional. Filter as described at 
     http://msdn.microsoft.com/en-us/library/windowsazure/dd894031.aspx
  select: Optional. Property names to select from the entities.
  top: Optional. Maximum number of entities to return.
  next_partition_key: 
     Optional. When top is used, the next partition key is stored in
     result.x_ms_continuation['NextPartitionKey']
  next_row_key: 
     Optional. When top is used, the next partition key is stored in
     result.x_ms_continuation['NextRowKey']
  '''
于 2013-12-08T21:24:29.837 に答える