問題タブ [sql-azure-federations]

ここには興味深い状況があります。Entity Framework でリポジトリ パターンを使用しているため、各データベース テーブルには、コンストラクターで DbContext のインスタンスを受け入れる独自の Repository クラスがあります。また、依存性注入に Ninject を使用しています。複数のリポジトリが DbContext を要求したときに、同じインスタンスが全体で使用されるように、特定の要求中にインスタンス化される単一のコンテキストを定義しました。これにより、UnitOfWork パターンに従うことができるため、複数のリポジトリで複数のことが発生し、1 回のコミットですべての変更がデータベースにコミットされます。

ここに問題があります。クライアント データを複数のデータベース (シャーディング) に分割する SQL Azure フェデレーションも使用しています。同じリクエスト内であるフェデレーション メンバー (データベース) から別のフェデレーション メンバー (データベース) にジャンプできる必要がありますが、注入されたコンテキストに依存する同じサービス/リポジトリ メソッドを使用できるようにしたいと考えています。最初に考えたのは、既存のコンテキストで USE FEDERATION sql コマンドを実行して次のデータベースに移動することでしたが、うまくいく場合とそうでない場合があるようです。ステートメントを実行すると、コンテキストの基礎となる接続が実際には新しいサーバーを指していることがわかりますが、何らかの理由で、そのコンテキストで実行されたクエリは以前の接続からの結果を返すことになります。複数のデータベースでコンテキストの同じインスタンスを使用することは、通常、新しいデータベースに接続するときに新しいコンテキストをスピンアップするため、ネイティブでサポートされているものではないと思います。残念ながら、Ninject を使用して動的に作成され、コンテキストの同じインスタンスを取得するリポジトリが多数あるため、新しいデータベースの新しいコンテキストをスピンアップしたとしても、既存のすべてのリポジトリを突然変更する方法はありません。最初のリクエストで作成されたものではなく、スピンアップしたばかりの新しいコンテキストに依存します。

考えられるいくつかの解決策を次に示しますが、それらを機能させる方法はわかりません。

1. 既存のコンテキストで使用されているデータベースを変更します (上記で説明したように動作していないようでした)
2. 既存のすべてのリポジトリが別のコンテキストに依存するようになるように、すべてのリポジトリの注入されたコンテキストを新しいものと交換します
3. コンテキストが要求されたら、コンテキストに必要なパラメータを渡すすべてのリポジトリの新しいインスタンスを何らかの方法で Ninject に要求します。

繰り返しになりますが、ここでの要点は、単一のコンテキストに依存するリポジトリとサービスのセットがあり、それらのサービスとリポジトリを再利用できるようにしたいが、すべてが依存しているコンテキストを交換または変更して、新しいサーバー。

フェデレーションで azure table1 の 2500 ～ 3000 行を更新しようとしています。フェデレーション外、同じ DB に格納されている table2 から。

ワーカー ロール ローカルを実行すると、azure-emulator で次のエラーが発生します。

に続く ：

ここで何が起こっているのですか？

フェデレーションでテーブルを作成しようとすると、このエラーが発生します。これを解決するにはどうすればよいですか? 私はアイデンティティを使用する必要があります。すべてが設定されています。しかし、フェデレーションを適用しようとすると、これが発生します。

前もって感謝します。

PEAR MDB2 sqlsrv ドライバーを使用して、windows sql azure データベースに接続したいと考えています。

これを使用して非連合データベースに接続できます

sqlsrv://username@server:password@server.database.windows.net:1433/mydatabase

しかし、連合データベースでは設定する必要があります

"MultipleActiveResultSets" => false

これも接続文字列で..

この余分なパラメータを渡すにはどうすればよいですか..助けてください

sqlsrv://username@server:password@server.database.windows.net:1433/mydatabase?op‌ tions="MultipleActiveResultSets=false"

これは余分な値を送信する正しい方法ですか?

現在、SQL Federated DB は 10 個のシャードに分割され、クライアント ID でフィルター処理されたデータのほぼ等しい部分になっています。

現時点では、フィルタリングされたクエリの実行でパフォーマンスの問題が発生しています。たとえば、特定のクライアントのクエリを実行すると、一部のシャードで 4000 行を返すのに 3 分以上かかる場合があります。ただし、同じシャードのフィルタリングされていない接続でまったく同じクエリを実行すると、タイムリーに 4 秒以内に返されます。注目すべき側面の 1 つは、速度が低下しているシャードには、データが少ないにもかかわらず、より多くのクライアントが含まれる傾向があることです。最も可能性の高いパフォーマンス阻害要因 (と私は信じています) は、インデックス作成と、フィルター処理された/フィルター処理されていない接続に結び付けられるものです。

検索しても、シャード全体のクエリ パフォーマンスやシャードでの特定のインデックス作成戦略に関する情報はあまり見つかりませんでした (Azure は明らかにインデックス付きビューをサポートしていません)。私の印象 (したがって、明確にする必要がある) は、インデックスはメンバーごとではなく、シャードのすべてのメンバーに適用されるということです。

前者の場合、この特定のシャードをリシャードすることを除けば、データのサイズではなく、クライアントの数だけが異なることを考えると意味がありません。これから試行するいくつかのことは、フィルタをインデックスに明示的に追加すること、またはフィルタを各クエリに追加することです。言うまでもなく、フィルター接続から離れることに満足していません.

他の誰かがこの問題を経験したことがありますか、またはフィルタリングされていない接続がフィルタリングされた接続よりも大幅に優れているという方向性を提供できる可能性がありますか?

前もって感謝します...

背景:

主なエンティティが顧客であるアプリケーションがあります。このアプリケーションのすべての情報は、顧客から始まります。これをなんらかのパーティショニングに使えたらいいなと思いました。Azure SQL Database をバックエンドとして使用するサービスを設計しました。

表は次のようになります (簡潔にするために、関連する部分のみを残しています)。

これにより、クレイジーなことを実行できるようになりました。すべての SQL 関連のものへのエントリ ポイントには、常に次のコマンドが最初に含まれます。

この場合、このステートメント:

また

問題なく動作し、特定の顧客のデータのみを処理します。CustomerId COLUMN は常にシステム関数 FEDERATION_FILTERING_VALUE から推測されます。

これで、問題なく単一のデータベースにすべての顧客を含めることができ、顧客は互いに分離されます。将来、そのうちの 1 つが大きくなりすぎた場合、その特定の顧客 ID でフェデレーションを SPLIT することができ、それをサポートするためにコードを変更する必要はありません。

それぞれの顧客を個別のフェデレーション データベースに格納できますが、それを使用するサービスはそれについて何も知りません。

私たちはソリューションに非常に満足しており、私はそれを思い付くのが非常に賢いと思いました. Microsoft が、今後登場する新しい azure データベース エディションで azure フェデレーション機能を廃止することを発表したのはつい最近のことです。詳細については、こちらとこちらをご覧ください。

私の問題を見ていただければ幸いです。私の代替案は何だと思いますか？Azure フェデレーションを使用していますか? また、どのように移行しますか?

ありがとうございました。