問題タブ [azure-table-storage]

Azure プラットフォームの開発を検討しています。SQL Azure から得られる完全なリレーショナルは必要ありません。代わりに Table Storage を使用することに非常に興味があります。

ここで実行する必要があるリレーショナルの 1 つのことは、ストレージ内のテーブル間の 1 対多および多対多の関係を表すことです。

通常のデータベースがそれらを内部的に表現するのと同じように、パーティションと行キーを持つ中間テーブルを使用してこれを表現する方法に非常に満足しています。

私が探している限られた程度の参照整合性を監視できるフロントエンドを作成するために、ストレージとそれにアクセスするものの間を仲介するためだけにワーカーサービスを作成する価値があるかどうか疑問に思っています.

クライアントの一部としてこれを簡単に行うことができますが、これらの参照にまたがるクエリが 3 つの異なるテーブルと通信する必要がある可能性が高いことを考えると、サービスをクラウドでホストすることでネットワーク レイテンシが低下するかどうか疑問に思っています。おそらく、これらのリクエストは、サービスとクラウドに投稿されたストレージの間ではるかに高速になるはずです。そのため、クラウドの外部からのリクエストは、複数ではなく 1 つだけになります。

これが有用な戦略である場合、それを行うための既存のツールはありますか? そうでない場合、何がうまくいくでしょうか、それとも目に見える利点はありませんか? SQL For Azure や、ビッグ データを Table Storage に格納し、ルックアップとテーブル参照を SQL に格納する異種ソリューションを使用する必要がありますか?

WebRole（WCFサービス）をAzureにデプロイする際に問題が発生しました。私のWebRoleは、中止するまで、少なくとも30分間はブジーを表示し続けます。Visual Studio 2010を介して展開します。トレース情報を探していますが、とというストレージテーブルを紹介しているブログがいくつかWADInfrastructureLogsTableありWADLogsTableます。

次のように、ストレージアカウントを使用して構成設定をセットアップしました。

ストレージアカウントにテーブルがまったくありません。HelloWorldアプリを正常にデプロイした後でもありません。私のBlobコンテナーはvsdeploy-およびwad-control-containerを保持し、4つのキューがあります。

これらのテーブルはどのように作成されますか？

Azureテーブルストレージにレコードを挿入しようとしたときに、「プロパティ値がテーブルサービスで許可されている値よりも大きい」という例外が発生します。

次は私のテーブル構造、文字列PartitionKey、String RowKey、string Id、文字列サイト、文字列名、byte []コンテンツ、
publicDateTimecreatedtimeです。

そして、コンテンツフィールドに83755バイトの配列（82KB）を保存しようとしていますが、他のフィールドは最大35文字です。

紺碧のストレージテーブルの行の最大サイズを教えてもらえますか？

以下は私が参照したURLです..そこに記載されている行は最大1MBを持つことができます。しかし、私のものは100KBを超えません。

リンク

ありがとう、

ゴピナス

Azure ストレージ テーブルに書き込む必要があるデータがあります。サンプル コードを参照できるブログまたは msdn 記事を教えてもらえますか? コードの 4 行目以降に進むのを手伝ってください。

null値についてAzureテーブルストレージを照会する適切な方法を知っている人はいますか? 私が読んだことから、それは可能です（ただし、開発ストレージではそれを妨げるバグがあります）。ただし、ライブ クラウド ストレージでこれを行うと、次のエラーが発生し続けます。

要求入力の 1 つが無効です。

これは、私がまとめた LINQ クエリの簡易バージョンです。

null をチェックせずにクエリを実行すると、問題なく動作します。考えられる解決策は、このクエリが返すコレクションに対して 2 番目のクエリを実行することです。必要に応じてそれを行ってもかまいませんが、このアプローチを最初に機能させることができるかどうかを知りたいです。

私が間違っていることが明らかな人はいますか？

トランザクションデータを保存するためにテーブルストレージを使用することを検討していますが、基本的に1日/月あたりの合計である非常に高レベルのレポートをサポートする必要があります。

私が持っているオプションのカップル：

• パーティション/行キー構造を使用し、合計を動的に実行します
  （例：20101101_ITEMID_XXXXXXXX（x = guidまたはtime、一意にする））次に、行キーの一部（ITEMID_201011）を使用して月のデータをクエリし、「タイプの「コスト」プロパティ。

  しかし、1000レコードのクエリ制限はこれによってどのように管理されますか？（つまり、1日に1000を超えるトランザクションがある場合、合計は困難になります）

• 別のレコードを使用してその日の合計を保存し、新しいレコードが追加されたらこれを更新し
  ます。たとえば、行キー「20101101_ITEMID_TOTAL」を使用して、日数の合計、月、または年の合計を照会します。

これを行うための最良の方法は何ですか？テーブルストレージを使用するこのタイプの要件の「ベストプラクティス」はありますか？

IDictionary を持つクラスがあります。このオブジェクトのサイズは、特定のサイズに固定されていません。これのアイデアは、私のオブジェクトの動的スキーマを持つことです。このオブジェクトを TableStorage に格納したいと考えています。これどうやってするの？そして、IDictionaryを使用してオブジェクト内でこの情報をストアから取得するにはどうすればよいですか??

ありがとう！！

Azureテーブルエンティティに配列を格納しようとしています。現在、ネイティブにサポートされている配列のタイプはバイト配列のみで、長さは64kに制限されています。サイズは十分ですが、long、double、timestampの配列をエンティティに格納したいと思います。

要求されたタイプに自分で複数のバイトをキャストできることは明らかですが、それを実現するためのベストプラクティスがあるかどうか疑問に思いました。

明確にするために、これらは単一のキーに関連付けられた固定長の配列（たとえば、1000セル）です。

リレーショナルデータベースのバックグラウンドから来て、私はドキュメント指向データベースに非常に迅速に移行することができます。最も価値のある「関係」の多くは、ドキュメントの階層によって維持されます。NoSQLのDODBバリアントの多くは、非常に豊富なクエリ言語も提供します。私が理解していると思うNoSQLのこのサブセット。

Azure Table Storage、S3、およびBigTableによって実装されたデータベーススタイルを中心に設計するための優れたリファレンスを探しています。私が見るサンプルはすべて、些細な実装のようです。

この空間でのデザインの重要な扱いを知っていますか？

私はまだCQRSスタイルのアーキテクチャに関連する基本的な（そして解決された）問題に苦労しています：

集約ルートのセットに依存するビジネスルールをどのように実装しますか？

例として、予約アプリケーションを取り上げます。コンサートのチケット、映画の座席、レストランのテーブルを予約できる場合があります。いずれの場合も、販売される「アイテム」の数は限られています。

イベントや場所がとても人気があると想像してみましょう。新しいイベントや時間帯の販売が開始されると、予約は非常に迅速に到着し始めます。おそらく1秒あたりの数が多くなります。

クエリ側では、大規模な拡張が可能であり、予約はキューに入れられ、自律コンポーネントによって非同期的に処理されます。最初は、予約コマンドをキューから削除するときに受け入れますが、ある時点で、残りのコマンドを拒否し始める必要があります。

限界に達したとき、どうやって知ることができますか？

予約コマンドごとに、ある種の店舗に問い合わせて、リクエストに対応できるかどうかを判断する必要があります。これは、その時点ですでに受け取った予約の数を知る必要があることを意味します。

ただし、ドメインストアがWindows Azureテーブルストレージなどの非リレーショナルデータストアである場合、SELECT COUNT(*) FROM ...

1つのオプションは、次のように、現在のカウントを追跡するだけの個別の集約ルートを保持することです。

• AR：予約（誰？何人？）
• AR：イベント/タイムスロット/日付（集計数）

2番目の集約ルートは最初の集約ルートの非正規化された集約ですが、基盤となるデータストアがトランザクションをサポートしていない場合、大量のシナリオでこれらが同期しなくなる可能性が非常に高くなります（これが私たちが試みていることです）そもそもアドレス）。

考えられる解決策の1つは、予約コマンドの処理をシリアル化して、一度に1つだけが処理されるようにすることですが、これはスケーラビリティ（および冗長性）の目標に反します。

このようなシナリオは、標準の「在庫切れ」シナリオを思い出させますが、違いは、予約をバックオーダーにうまく入れることができないことです。イベントが完売すると完売するため、補償措置がどうなるかわかりません。

そのようなシナリオをどのように処理しますか？