制限 - azure table storage 検索



Azureテーブルストレージのためのパーティショニングの設計 (1)

いくつかのコメント:

データの保存とは別に、データを取得する方法を検討して、設計を大幅に変更する可能性があります。 あなた自身に尋ねたいかもしれない質問のいくつか:

  • データを取得すると、特定のメトリックと日付/時間範囲のデータを常に取得しますか?
  • または、特定の日付/時間範囲のすべてのメトリックのデータを取得する必要がありますか? これが当てはまる場合は、フルテーブルスキャンを検討しています。 明らかに、複数のクエリ(1つのクエリ/ PartitionKey)を実行することでこれを避けることができます。
  • 最新の結果を最初に見る必要があるのですか、まったく気にしませんか? それが元の場合、RowKey戦略は(DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks).ToString("d19")ます。

また、PartitionKeyは文字列の値なので、 int値をstring値に変換して「0」プリパッティングして、すべてのIDが順番に表示されるようにすることもできます。そうしないと、1、10、11、..、19,2 、...など。

私の知る限りでは、Windows AzureはRowKeyなくPartitionKeyのみに基づいてデータをパーティション化します。 パーティション内では、 RowKeyは一意のキーとして機能します。 Windows Azureは同じノード内の同じPartitionKeyでデータを保持しようとしますが、各ノードは物理デバイスでありサイズ制限があるため、データは別のノードにも流れることがあります。

このブログ記事は、Windows Azure Storage Teamからお読みください。http : //blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows- azure-tables.aspx

UPDATE下記のあなたのコメントと上記の情報に基づいて、いくつかの数学を試してみましょう。 これは、ここに公開されている最新のスケーラビリティターゲットに基づいています。http : //blogs.msdn.com/b/windowsazurestorage/archive/2012/11/04/windows-azure-s-flat-network-storage-and-2012-scalability -targets.aspx 。 ドキュメントには、

単一テーブルパーティション - テーブルパーティションは、同じパーティションキー値を持つテーブル内のすべてのエンティティです。通常、テーブルには多数のパーティションがあります。 1つのテーブルパーティションのスループット目標は次のとおりです。

  • 秒あたり2,000エンティティ
  • これは単一のパーティションであり、単一のテーブルではないことに注意してください。 したがって、良好なパーティショニングを持つテーブルは、上記の全体的なアカウントターゲットである最大20,000エンティティ/秒まで処理できます。

今では、10〜20の異なるメトリック・ポイントを持っていると言いました。各メトリック・ポイントに対して、1分あたり最大1レコードを書きます。これは、最大20エンティティ/分/テーブルを書くことを意味します。 2000エンティティ/秒のスケーラビリティ目標。

今問題は読書のままです。 ユーザーがパーティションごとに最大24時間分のデータ(24 * 60 = 1440ポイント)を読み取ると仮定すると、 今では、ユーザーが1日にわたって20のすべてのメトリックのデータを取得すると仮定すると、各ユーザー(したがって各テーブル)は最大28,800のデータポイントをフェッチします。 あなたのために残されている質問は、このような要求が、そのしきい値を満たすために1秒あたりに何回得ることができるかということです。 この情報を何らかの形で推測できる場合は、アーキテクチャーのスケーラビリティーに関するいくつかの結論に達することができると思います。

私はこのビデオも見てみることをお勧めします: http : //channel9.msdn.com/Events/Build/2012/4-004

お役に立てれば。

私は、1秒間に約200回の読み上げという、長い期間にわたってデータを収集するソフトウェアを持っています。 これは、SQLデータベースを使用しています。 私はAzureを使用して、古い「アーカイブされた」データを多く移動したいと考えています。

ソフトウェアはマルチテナントタイプのアーキテクチャを使用しているので、私は1人のAzure Tableを使用する予定です。 各テナントはおそらく10-20の異なるメトリックを監視しているので、メトリックID(int)をパーティション・キーとして使用する予定です。

各メトリックは1分あたりの読み取り量が1つしかないので、私はRowKeyとしてDateTime.Ticks.ToString( "d19")を使用する予定です。

しかし、私はこれがどのように拡大するかについて、少し理解が不足しています。 誰かがこれをクリアできるようになることを期待していました:

パフォーマンスのために、Azureはパーティクルキーでテーブルを分割し、すばやく素早く処理できるようにします。 この場合、メトリックごとに1つのパーティションが作成されます。

しかし、私のrowkeyは約5年間でデータを表現する可能性があるため、私は約250万行を見積もっています。

Azureは十分な賢さを持っていますか?また、Rowkeyに基づいて分割するか、将来のボトルネックで設計するのですか? 私は通常、時期尚早に最適化しないことを知っていますが、Azureのようなものは通常のように賢明ではないようです。

私が正しい行にいるかどうか、または私のデータをより多くのテーブルに分割すべきかどうかを私に知らせるAzureのエキスパートを探しています。