0

worker ロールまたは web ロール内でホストされているアプリケーション内のエラーをログに記録するために、windows azure テーブルを使用しています。クラスのどのコンポーネントがエラーを記録したかを簡単に識別できるように、テーブルに十分な情報を記録しています。

Component Id (完全修飾クラス名) がパーティション キーとして使用され、ランダムな一意の Guid が行キーとして使用されます。

このログ情報は ASP.NET MVC Web サイトに表示され、管理者はコンポーネント ID、日付範囲、役割 ID、重大度などのフィルター基準に基づいてこのログを検索できます。

これは、テーブルが小さくなるまでうまく機能します。Azure テーブルに大量のレコード (200000 以上) が含まれると、Azure テーブルのフィルター処理に時間がかかりすぎてタイムアウトになります。テーブルのクエリに .NET Azure Storage API を使用しています。

返された結果セットのページングも必要でしたが、Azure テーブルでは、返されたレコードの正確なカウントが得られないようです。

Azure Storage API を使用してフィルターを適用し、現在のページ番号に基づいてデータを取得しようとしましたが、機能しません。テーブル構造、特にパーティションキーと行キーを再設計する必要があるかもしれないことは理解していますが、どのように進めればよいかわかりません。

4

3 に答える 3

1

テーブル ストレージを使用する場合、パーティション キーと行キーの 2 つの「インデックス付き」プロパティしかありません。大量のデータがある場合、他のフィールドでの検索は非常に遅くなります。

ページング システムを実装するとき、またはデータを並べ替えるときは、行キーを操作する必要があります。行キーは、データの順序を定義します (並べ替え順序は辞書順です)。

データの並べ替えと順序付けの詳細については、Steve のブログ投稿をご覧になることをお勧めします: Windows Azure で数値をキーとして使用する

于 2012-06-09T07:34:16.577 に答える
0

多くのカスタム フィルターが必要な場合、テーブル ストレージでは最高のパフォーマンスが得られない可能性があります。可能であれば、SQL Azure の使用を検討してください。テーブル ストレージのパフォーマンスを向上させるには、次を試すことができます。

  1. カスタム フィルタは使用しないでください。パーティション/行キーを使用して結果のみをフィルター処理します。これにより、最高のパフォーマンスが得られます。

  2. 各パーティションを小さくします。小さなパーティションをスキャンする方が、大きなパーティションをスキャンするよりも高速です。

ページングに関しては、クロス パーティション クエリを使用しない限り、ページングは​​期待どおりに機能するはずです。20 個のエンティティを要求すると、正確に 20 個のエンティティ (非常に多い場合) が返されます。ただし、パーティション境界が検出された場合は、新しいページが必要です。たとえば、15 番目に一致するエンティティが見つかったときにパーティション境界が検出された場合、この要求では 15 エンティティのみが返されます。次のパーティションをクエリするには、新しいリクエストを作成する必要があります。パーティションを小さくしておくと、この問題がより頻繁に発生する可能性があります。したがって、必要に応じて次のパーティションを自動的に照会するようにシステムを設計する必要があります。

また、テーブル ストレージのページングは​​ページ番号に基づいていないことに注意してください。継続トークンに基づいています。詳細については、 http://msdn.microsoft.com/en-us/library/dd135718.aspxを参照してください。

于 2012-06-11T05:20:08.597 に答える
0

そのような場合、Azure テーブルにログを保存するために作成したロガー - QLog をお勧めします。NuGet 経由で取得できます。必要な方法でログを照会できる QLogBrowser が付属しています。GitHubプロジェクトサイトはこちら.

于 2012-12-15T22:02:14.823 に答える