問題タブ [azure-elastic-scale]

現在、Elastic Sc​​ale を使用して、既存のデータの大量のマッピングをシャードマップに挿入することをテストしています。プロセス全体に時間がかかることがわかりました。1 秒あたり約 10 個のマッピングを挿入しています。マッピングのバッチを挿入するか、ストアドプロシージャを介して直接挿入するなど、挿入を高速化する方法はありますか?

データモデルを Azure Elastic Sc​​ale に移行しています。

いくつかのテストといくつかの経験の後、私はそれが単純であり、そのようなアプローチでコードがきれいで維持しやすいものであることに恋をします.

大きな質問が 1 つあります。シャーディング キーはどこで定義されていますか? Visual Studio からダウンロードしたサンプルに関する情報を見つけることができず、これが単純な答えであることに勝るものはありません。

Microsoft が提供するサンプルでは、​​デフォルトのシャーディング キーはCustomerIdですが、そのキーへの参照がどこで行われるかわかりません。

構成ファイルの ShardMapName にある可能性はありますか?

前もって感謝します。

参照テーブルの考え方を正しく理解しているかどうかはわかりません。私の考えでは、すべてのシャードに同じデータを含むテーブルです。私が間違っている？参照テーブルにデータを挿入して、すべてのシャードでデータを乗算する方法がわからないため、質問しています。それともそれは不可能ですか？誰でもこの問題を明確にできますか?

定期的に異なるデータベース インスタンス間でデータを移動する必要があるという要件があります。(たとえば、一部の顧客は、より良いパフォーマンスに対してより多くの料金を支払うことを厭いません)。したがって、これは 1 回限りではありません。

データベース テーブルには参照整合性があります。顧客データを移行するたびに SQL スクリプト (またはその他の方法) を書き換えずにこれを行う方法はありますか?

外部キー関係/参照整合性を維持しながら、複数のデータベースのテーブル間でデータを移動する方法は? . ただし、データを移行するたびにスクリプトを作成しているようです (このスレッドの回答を誤解していた場合は、訂正してください)。

ありがとう

編集：

• どちらのサーバーも SQL Server 2012 (同じバージョン) を使用しています。Azure SQL Server データベースです。
• それらは必ずしもリンクされているわけではありません（それらの間にファイアウォールはありません）
• データベース全体ではなく、一部のデータのみを転送しています。これは、より多くの支払いを選択した特定の顧客のみを対象としています。
• スキーマは両方のデータベースでまったく同じです。

ここでMicrosoft が提供するサンプル アプリをいじってみます。これは、新しいデータベースとそのシャードなどの作成には問題なく機能しますが、単一のシャードを持つ既存の DB に接続しようとすると失敗します。

という名前のクラスがあり、シャードされた Azure データベースからShardManagementUtils取得する次のメソッドを提供します。RangeShardMap<T>

私のデータベースには 1 つのシャードがあり、シャーディング データは に保持されGlobal Shard Map (GSM)ます。このメソッドを正しいShardMapManagerとを渡して呼び出すとshardMapName、次のようになります。

スローされる例外は次のとおりです。

テーブルを確認したところ、__ShardManagement.ShardMapsGlobalシャード マップ情報が含まれていました。RangShardMapでは、最初の行が既に存在する場合、なぜ最初の行が取得されないのでしょうか?

私は何を間違っていますか。あなたの助けに感謝します。

Entity Framework で TPH を使用してテーブル構造を指定した場合。

エンティティ フレームワークには派生クラスのテーブルに基本クラスのプロパティが含まれていないため、スプリット マージ操作のエラスティック スケール スキーマ情報を構成するにはどうすればよいですか? 具体的には、ポイント マップのシャード キーである Tenant_ID です。

更新: ContactLink は抽象的ではありません。

更新 2: ContactLink も DbContext にあり、ContactLinkCustomer とは別に照会されることに注意してください。

更新 3: 私は TPH を使用していません。実際には TPT を使用しています。これが、ディスクリミネーターを持つ単一のテーブルではなく、複数のテーブルを引き起こした原因です。

最近、Azure Elastic Sc​​ale DB に移行しました。したがって、別のシャードを作成する必要がある場合、DBA は既存のシャードを手動で分割します。splitそのため、既存のシャードまたはmerge複数のシャードを簡単に 1 つにできるように、そのプロセスを自動化するタスクが与えられました。私は、Elastic database Split-Merge tool tutorialを学び、フォローしています。ここの別のチュートリアルでは、要件と制限のセクションで次のように述べています。

現在、これらのシャードで分割/マージ操作を実行するには、シャードが存在し、シャード マップに登録されている必要があります。

そのため、別のシャードを手動で作成し、それをシャード マップに登録する必要があります。そのためには、別のツールを使用する必要がある場合があります。同様に、すべてのシャード テーブルと参照テーブルのスキーマは、分割/マージ/移動操作の前にターゲット シャードに存在する必要があります。

したがって、分割/マージのこの機能はまだ自動化されていませんか、それとも間違った場所を見ているのでしょうか?

これらすべての操作を自動化してほしい。そのための完全なソフトウェアまたはチュートリアルを教えてもらえますか?