1

ATS（Azure Table Storage）を使用して500エンティティ/秒/パーティションを回避する方法はありますか？ダーティリードでOK。挿入がすぐに読み取れない場合は、OKです。

いくつかの大きなテーブルをSQLからATSに移動しようとしています。

  • スケール：これらのテーブルのため、サイズはSQLAzureの150GBの制限を超えています

  • 挿入速度：クエリ速度の転置インデックス。挿入順序はテーブルクラスター化インデックスによってソートされないため、SQLテーブルが急速に断片化されます。ATSには、SQLよりも挿入の利点がある可能性があります。

  • 費用：ATSの月額費用は低くなります。ただし、ATSは数百万行という高いロードコストがあり、ロードの順序がパーティションごとではないため、バッチ処理できません。

  • クエリ速度：検索が1つのpartitionKeyだけで行われることはほとんどありません。検索には、SQLコンポーネントと0個以上のATSコンポーネントが含まれます。このATSクエリは、常にpartitionKeyとreturnrowKeysによって行われます。partitionKeyでの生の検索は高速です。問題は、エンティティ（行）を返す時間です。特定のpartitionKeyには、平均1,000のrowKeyがあります。これは、500エンティティ/秒/パーティションで2秒です。ただし、3分以上に相当する100,000を超えるrowKeyを持つpartitionKeyがいくつかあります。一度に10,000行をSQL​​で返します。結合の力で、whereでそれらの行を考慮するために100,000行を下げる必要がないため、クエリは10秒を超えません。

  • ATSでこの選択されたエンティティの速度の周りにありましたか？スケールとインサート速度については、ATSに行きたいです。

WindowsAzureストレージの抽象化とそのスケーラビリティのターゲット

WindowsAzureテーブルを最大限に活用する方法

WindowsAzureテーブルストレージのスケーラブルなパーティション化戦略の設計

変更されないクエリ結果のエンティティ追跡をオフにします。context.MergeOption=MergeOption.NoTracking;

4

2 に答える 2

2

考えられる回避策の1つは、複数のパーティションやテーブルにデータをストライプ化し、すべての（サブ）パーティションに並列にクエリを実行して、結果をマージすることです。

たとえば、パーティション間でストライピングを行う場合、パーティションキーの前に1桁を追加すると、パーティションのスケーラビリティが10倍になる可能性があります。

したがって、パーティションキー、たとえばABCDEFGHは、0ABCDEFGHから9ABCDEFGHにサブパーティション化できます。
パーティションへの書き込みが行われ、プレフィックス桁がランダムまたはラウンドロビン方式で生成されます。読み取りは、10個のパーティションすべてを並行して照会し、結果をマージします。

テーブル間でストライピングを行う場合、N個のテーブルの1つをランダムに、またはラウンドロビン方式で書き込み、同様に並行してクエリを実行できます。

于 2012-07-11T23:38:45.110 に答える
1

編集：私は当初、制限は500トランザクション/パーティション/秒であると述べていました。それは正しくありませんでした。元の質問で述べたように、制限は実際には500エンティティ/パーティション/秒です。

これは、計算したクエリ速度にも当てはまります。ATS PartitionKeyをクエリして、1000個のエンティティを返す場合、単一のエンティティを返すよりも少し長く、おそらく数百ミリ秒かかる可能性があります。一方、クエリが1000を超えるエンティティを返す場合、1000行の各セットには本質的に独立したトランザクションが必要であり、シリアルで実行する必要があるため、処理速度は大幅に低下します。

あなたが何をしているのかは私には完全にはわかりませんが、多くの質問のように聞こえます。キー以外の列でのATSのクエリは、非常に遅くなる傾向があることに注意してください。多くのことを行っている場合は、代わりにSQLAzureフェデレーションとファンアウトクエリを使用した方がよい場合があります。

于 2012-07-11T19:10:29.213 に答える