SQLからへの移行 NoSQL Databases

リレーショナルデータベースからデータを移行する手順 NoSQL

.NETアプリケーションでリレーショナルデータベースを使用することには、既存のハードウェアを置き換えずに（スケールアップ）より多くの負荷を処理できないことや、行と列などの厳密なデータモデルを更新できないことなど、いくつかの制限があります。これらの課題に直面している場合は、データベースを次の場所に移行することをすでに決定している可能性があります。 NoSQL。それでも確信が持てない場合は、読みたいと思うかもしれませんなぜ NoSQL?

データベースレイヤーをスケーリングするオプションがなく、データを次の場所に移動することを選択した場合を考えます。 NoSQL、移行の困難な作業は、この飛躍を阻止することかもしれません。

移行は大きなタスクですが、ステップに分割すると、非常に整理された方法でアプローチできるため、生活が楽になります。このホワイトペーパーは、移行プロセスを6つの論理的なステップで整理するのに役立ちます。

ASP.NET Core パフォーマンスのボトルネック — 6つの論理ステップでの移行プロセス

これらの簡単な手順に従うと、移行プロセスで役立つはずです。このホワイトペーパーでは、 NosDB、.NET NoSQL ドキュメントデータベース。そうでない場合は、ウェブサイト。以下に、前述のプロセスの詳細を示します。

ステップ1：スコープを特定する

最初の最も重要なステップは、ビジネスモデルとデータベーススキーマを理解することです。また、アプリケーションがこのデータにどのようにアクセスするか、およびデータベースとの間のデータフローを完全に理解する必要もあります。これは、次の 2 つの重要な情報を特定するのに役立ちます。

最もアクセスされるデータベーススキーマの部分（読み取り、書き込み、またはその両方）
グループ化されたデータ、つまり読み取りと書き込みのために常に一緒にアクセスされるデータ。

この情報があると、残りのステップで重要な決定を特定するのに役立ちます。したがって、これも最も重要なステップです。

ステップ2：特定する NoSQL セットアップ要件

ビジネスモデルとデータフローの理解が完了すると、展開方法についていくつかの大まかな決定を下すことができるようになります。 NoSQL ビジネス要件に基づいたクラスター。たとえば、実行中のアプリケーションの現在の数、ユーザーの数、およびアクセス率を書き留めることは、いくつかの重要なメトリックです。データのどの部分が非常に機密性が高いか、つまり、すべてのコストでバックアップが必要であることに注意することは、レプリカノードの展開戦略を決定するのにも役立ちます。

から NoSQL database は分散データベースであり、分散の性質を活用してビジネス要件に応じて展開できます。スケーラビリティに加えて得られる最大の利点は、 NosDB さまざまなGEOロケーションにまたがるクラスターシャード。これにより、アプリケーションの地理的な場所の近くにシャードをデプロイし、コストのかかるネットワークトリップを回避できます。また、アプリのパフォーマンスが向上します。

ここで行っているのは、要件をスケッチすることだけであることを忘れないでください。コレクションを特定、作成、最適化した後、これらの設定を確実に再検討します。

ステップ3：JSONコレクションを変換して最適化する

デプロイメントクラスターの基本的な要件が揃ったので、「スケッチ」によって最適化戦略が決まります。

テーブルをコレクションに変換する

まず、テーブルをリレーショナルデータベースからコレクションに変換し、列を属性に変換するだけです。これは 正規化 リレーショナルデータベースからのデータ。

ドキュメントを埋め込んでデータを非正規化する

次に、する必要があります 非正規化 分離されたテーブル、つまり、別のテーブルと関連付けられていない限り、何も意味しないテーブル。関係用語では、分離されたテーブルは ジャンクションテーブル。例えば、注文詳細 Northwindデータベースでは、Orderを参照して言及すると、より意味があります。したがって、正しい選択は、OrderDetailsを内部に埋め込むことです。注文ドキュメント。

関係を変換する

さて、あなたが残したのは、それぞれのドキュメントを含むコレクションです。 ジャンクションテーブル それらの中に埋め込まれています。しかし、多対多、XNUMX対多、その他の関係についてはどうでしょうか。ここで、自然にグループ化されたデータと一緒にアクセスされたデータに関する知識が役立ちます。

NorthWindデータベースの移行例顧客 & 注文テーブルは関連していますが、常に一緒にアクセスされるとは限りません。したがって、を埋め込むことは意味がありません顧客オブジェクト内部注文書。さらに、顧客文書不必要にデータを複製しますが、これは可能な限り避けたいと考えています。それ以外の場合、顧客プロファイルをXNUMX回変更すると、アプリケーションはすべての変更を行う必要があります。注文.顧客ドキュメント。不要な計算コスト。

一方、カテゴリは、製品がフェッチされるたびにアプリケーションで常に必要になります。したがって、これは埋め込みに適した候補です。また、JSONドキュメントの優れている点は、オブジェクトを充実させるために、配列やJSONドキュメントの配列もサポートできることです。

ハイブリッドモデル-最適化と非正規化

から NoSQL スキーマはアプリケーションのデータフローに基づいています。コレクションに埋め込みと非埋め込みの両方を維持できるという利点がある場合は、ハイブリッドモデルを採用してください。

前のページで参照されているサンプルのNorthwindデータベースでは、この現象はカテゴリー & プロダクトテーブル。シナリオは、プロダクトアクセスされる場合、アプリケーションはそのことを知る必要がありますカテゴリー。しかし、アプリケーションはまた見つける必要があります製品 by カテゴリー.

Status カテゴリー別のテーブルに保持されていた場合、単一の製品フェッチはXNUMXつのデータベース呼び出しを意味し、XNUMXつはフェッチするためのものです。プロダクトと他はそれぞれをフェッチしますカテゴリーしたがって、追加のネットワークコスト。だけならカテゴリーが埋め込まれている場合、すべてのカテゴリを見つけるには、次のSQLステートメントを実行する必要があります。

SELECT DISTINCT product.Category.CategoryName FROM Products;

単純なSQLクエリですが、あまり効率的ではありませんか？だから答えは維持することですカテゴリー別のコレクションに文書化しますが、製品に必然的に必要な部分のみを埋め込みます。これはと呼ばれます ハイブリッドモデル.

たとえば、このシナリオでは、アプリケーションが製品ドキュメントをフェッチするときに、カテゴリー名前とカテゴリー説明。したがって、を埋め込む必要はまったくありません。カテゴリーすべての製品ドキュメントの画像。実際、複製すると、多くの不要なストレージが必要になり、ドキュメントサイズが大きくなるため、コストのかかるネットワークトリップが発生します。

これはハイブリッドモデルの完全なユースケースであるため、コレクションは次のように形成されます。

"Product" {
   "name": "string",
   "category": {
      "name": "string",
      "description": "string",
   }
}

と保存カテゴリー個別にも：

"Category" {
   "name": "string",
   "description": "string",
   "picture": byte[]
   }
}

流通戦略を決定する

次に決定するのは、コレクションの配布戦略の可能性です。セットアップ要件の最初のスケッチは、これに直接影響します。

配布戦略にはXNUMXつのオプションがあります。

範囲ベースの分布： この戦略により、各シャードに指定された範囲に従って、データがノード間でどのように分散されるかを定義できます。たとえば、 NosDB クラスターは、ニューヨークとロンドンにXNUMXつのシャードで分散されたGEOであり、ニューヨークに存在するアプリケーションによって生成および必要とされるデータは、同じGEOの場所にある必要があります。これにより、ネットワークコストが最適化されます。この戦略は主にGEO分散クラスターで使用されますが、他のユースケースもあります。
ハッシュベースの配布： ハッシュを使用すると、データをシャード全体に均一に分散できるため、負荷も均一に分散できます。この戦略は、GEO分散クラスターには最適ではありませんが、 NosDB 単一のデータセンター内のクラスター。
シングルシャードコレクション（配布を無効にする）： これにより、コレクションの配布が完全に無効になります。データセットが小さい場合、または特に単一のマシンにデータセットを配置する場合は、このオプションを使用します。

配布戦略を決定した後、コレクションの最適化と展開戦略を再検討して、それらをさらに最適化できるかどうかを確認することをお勧めします。決定に達するには、通常、数回の反復で十分です。

ステップ4：データを移行する

最後に、いくつかの激しいブレーンストーミングの後、ここに比較的簡単な部分があります。つまり、リレーショナルデータベースから NoSQL database.

まず、コレクションとJSONドキュメントを表す.NETオブジェクトを作成します。はい！ .NET APIは.NETオブジェクトをJSONドキュメントに自動的に変換するため、データを挿入するためにORMは必要ありません。（ただし、同梱されているADO.NET統合を使用することもできます。 NosDB).

次に、リレーショナルデータベースにアクセスし、これらの.NETオブジェクトにデータを入力して、 NoSQL database。によって提供されるCLRトリガーおよびCLRUDFを使用することもできます NosDB 移行を支援します。

データを移行したら、今度はアプリケーションを移行して、コレクションとドキュメントの観点からデータを採用します。それなし NosDB ADO.NETまたはCLRトリガーとUDFを使用するオプションはありませんが、APIは引き続き使用できます。

ステップ5：アプリケーションを移行する

動作中の.NETアプリケーションをに移行する方法は複数あります NosDB. NosDB SELECT、INSERT、UPDATE、DELETEなどのSQL操作をサポートします。 SQL操作を使用すると、アプリケーションを移行するための学習曲線が大幅に短縮されます。つまり、慣れ親しんだ構文を使用できます。でデータベースクラスターを管理することもできます NosDB SQLを使用します。

NosDB データベースにアクセスできるすべての複数の方法でSQLをサポートします。

.NET API
- ADO.NET
- LINQ
Java API
REST API

また、サーバー側APIを使用して、MapReduceなどのフレームワークを使用することで配布の能力を活用し、アプリケーションのパフォーマンスを向上させることもできます。使用していない場合 NosDB APIを直接呼び出すオプションしかありません。 SQLとADO.NETは、によってのみ提供されます NosDB.

ステップ6：移行を検証する

移行後、検証はプロセス全体の最後のステップです。すべてのテストを検証し、移行されたデータとアプリケーションを検証します。このステップは完全にあなたとあなたのビジネスプロセス次第です。新しく組み込まれたベンチ NoSQL database。現在のクラスター構成の制限を確認し（ただし、いつでもスケールアウトできます）、次のような適切なツールを身に付けてください。 NosDB 単一の場所からクラスター全体を管理および監視するためのManagementStudio。

それでおしまい！これらの手順に従うと、リレーショナルデータベースから NoSQL database 論理的な6ステップのプロセスで。