問題タブ [azure-cosmosdb]

質問は、「平らにするか、平らにしないか」と言い換えることもできます。

ネストされた JSON ドキュメントを DocumentDB コレクションに格納する場合、それらのネストされた構造に対するクエリは、それらのネストされた構造を別のコレクションにフラットなドキュメントとして独自に格納した場合と同等に実行されますか?

問題のデータは一度書き込まれ、(おそらく) 更新されることはありません。レポートのパフォーマンスは、要件リストの一番上にあります。

一方では、ネストされた構造にデータを格納することは、ノースキーマ/ノー SQL テクノロジーを利用する「正しい」方法のように思えます。つまり、当然のことながら、ヘッダー データと詳細データをすべて 1 か所でコンテキスト内に関連付けたいと考えます。しかし、Web アプリケーションからそのコレクションに関するレポートを同時に実行しながら、1 分間に数千行を書き込んだら、スケーリングして実行し続けることができるでしょうか?

または、その詳細データを平坦化して、ヘッダー データの関連部分を詳細コレクションの各行に重複して格納する方がよいでしょうか? 長年の RDBMS 開発者/ユーザーとして、データを冗長に格納したくない傾向がありますが、高性能を優先してその考えを手放すべきでしょうか?

フラットなデータ構造は、DocumentDB でより効率的にクエリを実行し、どの程度のマージンがあるのでしょうか? つまり、それを行うことで何をあきらめているのでしょうか? また、パフォーマンスが最優先事項 (ただし唯一ではない) である場合、それだけの価値があるでしょうか?

どうやらランダムに DocumentDB からドキュメントを取得できません。デバッグできます。以下のメッセージで失敗し、再試行して動作します。これが私の MAC アドレスに関係している場合は、別のワークステーションからも試してみましたが、結果は同じでした。

Microsoft.Azure.Documents.UnauthorizedException、メッセージ: {"エラー":["HTTP 要求で見つかった MAC 署名は、計算された署名と同じではありません。サーバーは次の文字列を使用して署名しました - 'post\ndocs\nmo1oanohoga=\nwed 、2015 年 2 月 25 日 12:35:57 GMT\n\n'"]}

どうすれば a) これを報告し、b) 何が起こっているのかを理解しようとするでしょうか?

Azure ポータル ツールを使用してクエリを実行できる documentDb インスタンスがあります。

次のようなコードで同じクエリを書くと:

このエラーが発生しています：

System.AggregateException: 1 つ以上のエラーが発生しました。---> Microsoft.Azure.Documents.NotFoundException: クエリ '$resolveFor' に指定された値 'SELECT * FROM TI WHERE TI.INDEX = 1' は無効です。Microsoft.Azure.Documents.BackoffRetryUtility`1.d__0.MoveNext() で

正常に機能する他のクエリがあります。「インデックス」を使用すべきではないかどうか疑問に思っていますか?

前もって感謝します

こんにちは、16 個のコレクションを使用して、オブジェクトあたり 5 ～ 10k の範囲の約 3 ～ 400 万の json オブジェクトを挿入しています。ストアド プロシージャを使用してこれらのドキュメントを挿入しています。22 の容量ユニットがあります。

私のC＃コードは次のようになります

私が直面している問題は、挿入しようとする 400k のドキュメントのうち、エラーが発生せずにドキュメントが見逃されることがあります。

アプリケーションは、クラウド上にデプロイされた worker ロールです。documentDB に挿入するスレッドまたはインスタンスの数を増やすと、失われるドキュメントの数がはるかに多くなります。

問題が何であるかを把握する方法。事前に感謝します。

INDocumentDB クエリでステートメントを使用することは可能ですか? お気に入り：

OR制限があるので使いたくない（6個のみ）

ほとんどの Azure サービスでは、ストレージ エミュレーターなどのエミュレーターをローカル マシンで実行できます。これにより、資格情報を実際の Azure ストレージ アカウントに、Azure Web サイトのアプリ設定として保存できます。ローカルでは、web.config にエミュレーターへの資格情報があります。

しかし、Azure DocumentDB で同じ種類のセキュリティを実現するにはどうすればよいでしょうか? 資格情報をローカルの web.config に保存したくないのですが、同時に、開発時にアプリケーションをローカルで実行できるようにする必要があります。私が理解しているように、DocumentDB 用のエミュレーターはありませんか? そして、エンドポイントと認証キーは、私が作成するすべての DocumentDB で同じですか?

私の質問をまとめると、Azure DocumentDB を開発および使用する際に認証キー/エンド ポイントを処理するためのベスト プラクティスは何ですか?

ここ数年、Microsoft は「テーブル ストレージ」と呼ばれる「NoSQL」キー/値ストレージを提供しています ( http://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-テーブル/ )

Table Storage は、高いパフォーマンス、スケーラビリティ (パーティショニングによる)、および比較的低コストを提供します。テーブルの主な欠点は、パーティション キーと行キーのみにインデックスを作成できることです。そのため、値に対してクエリを実行するのは非常に非効率的です。

最近、Microsoft は「DocumentDB」と呼ばれる新しい「NoSQL」サービスを発表しました ( http://azure.microsoft.com/en-us/documentation/services/documentdb/ ) 。

プロパティのリストを格納する代わりに (Tables のように)、DocumentDB は JSON オブジェクトを格納します。オブジェクト全体にインデックスが作成されるため、格納されたオブジェクトのすべてのプロパティとネストされたプロパティに基づいて効率的なクエリを作成できます。

Microsoft は、DocumentDB は高いパフォーマンスとスケーラビリティも提供すると述べています。

もしそうなら、なぜ DocumentDB よりも Table Storage を使用するのでしょうか? DocumentDB は Tables と同じ機能を提供するように思えますが、あらゆるものにインデックスを付ける機能などの追加機能を備えています。

DocumentDB と Table Storage を比較して、それぞれの長所と短所を強調していただければ幸いです。

.createDocument()コレクションに 200 未満のドキュメントを挿入するために呼び出すと、次のエラーが発生します。これは通常、150 回目の呼び出しのあたりで発生し始めます。Node.js SDK を使用しています。これが発生した場合、データベースで実行されている他の操作はありません。

{ code: 429, body: '{"code":"429","message":"Exception: Microsoft.Azure.Documents.RequestRateTooLargeException, message: {\"Errors\":[\"Request rate is large\" ]}、リクエスト URI: rntbd://10.100.136.85:14900/apps/1240113d-9858-49b9-90cb-1219f9e1df77/services/itsupportrequests-ServerService-1/partitions/d7253667-671b-4f4e-ac84-a13b7d3db/replicasf5a/ 130701880511768464p\r\nActivityId: 5726e6b5-7955-4b39-b306-4903b9f69b36"}' }

これは、10 番目のクラス A セクションのすべての学生を取得するために DocumentDB のページングを実装しようとしているコードです。

コンソールアプリケーションでは問題なく動作しています。

しかし、Web アプリケーションで実行しようとすると、非同期呼び出し (つまり、query.ExecuteNextAsync()) でプロセスが終了し、例外も発生しません。

コンソール アプリケーションでは実行されているのに、Web アプリケーションでは実行されていない理由がわかりません。

これで何か問題がありますか？

または、結果を取得するためのより良い方法はありますか?

どんな助けでも大歓迎です。

前もって感謝します。