翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

データベース分解のための結合と結合の分析

このセクションでは、モノリシックデータベースの結合パターンと結合パターンを分析して分解をガイドするのに役立ちます。データベースコンポーネントがどのように相互作用し、相互に依存するかを理解することは、自然なブレークポイントを特定し、複雑さを評価し、段階的な移行アプローチを計画するために不可欠です。この分析では、隠れた依存関係を明らかにし、即時の分離に適した領域を強調し、変換リスクを最小限に抑えながら分解作業を優先するのに役立ちます。結合と結合の両方を調べることで、変換プロセス全体でシステムの安定性を維持するために、コンポーネントの分離シーケンスについて情報に基づいた決定を行うことができます。

結合と結合について

カップリングは、データベースコンポーネント間の相互依存度を測定します。適切に設計されたシステムでは、1 つのコンポーネントへの変更が他のコンポーネントに与える影響を最小限に抑えながら、疎結合を実現したいと考えています。結合は、データベースコンポーネント内の要素が連携して、明確に定義された 1 つの目的にどの程度役立つかを測定します。高い結合は、コンポーネントの要素が強く関連し、特定の関数に焦点を当てていることを示します。モノリシックデータベースを分解する場合は、個々のコンポーネント間の結合と結合の両方を分析する必要があります。この分析は、システムの整合性とパフォーマンスを維持しながらデータベースを分割する方法に関して、情報に基づいた意思決定を行うのに役立ちます。

次の図は、結合性が高い疎結合を示しています。データベース内のコンポーネントは連携して特定の関数を実行し、1 つのコンポーネントに対する変更の影響を最小限に抑えます。これは理想的な状態です。

次の画像は、結合性が低く結合性が高いことを示しています。データベースコンポーネントは切断され、変更は他のコンポーネントに影響を与える可能性が高くなります。

モノリシックデータベースの一般的な結合パターン

モノリシックデータベースをマイクロサービス固有のデータベースに分解するときによく見られる結合パターンがいくつかあります。これらのパターンを理解することは、データベースのモダナイゼーションイニシアチブを成功させるために不可欠です。このセクションでは、各パターン、その課題、および結合を減らすためのベストプラクティスについて説明します。

実装結合パターン

定義: コンポーネントはコードレベルとスキーマレベルで緊密に相互接続されています。たとえば、customerテーブルの構造を変更するとorder、、inventory、および billingのサービスに影響します。

モダナイゼーションの影響: 各マイクロサービスには、独自の専用データベーススキーマとデータアクセスレイヤーが必要です。

課題:

結合を減らすためのベストプラクティス:

一時的な結合パターン

定義: オペレーションは特定のシーケンスで実行する必要があります。たとえば、インベントリの更新が完了するまで、注文処理を続行することはできません。

モダナイゼーションの影響: 各マイクロサービスには自律的なデータ管理が必要です。

課題:

結合を減らすためのベストプラクティス:

デプロイ結合パターン

定義: システムコンポーネントは 1 つのユニットとしてデプロイする必要があります。たとえば、支払い処理ロジックを少し変更するには、データベース全体を再デプロイする必要があります。

モダナイゼーションの影響: サービスあたりの独立したデータベースデプロイ

課題:

結合を減らすためのベストプラクティス:

ドメイン結合パターン

定義: ビジネスドメインはデータベース構造とロジックを共有します。たとえば、customer、、orderおよび inventoryドメインはテーブルとストアドプロシージャを共有します。

モダナイゼーションの影響: ドメイン固有のデータ分離

課題:

結合を減らすためのベストプラクティス:

モノリシックデータベースの一般的な結合パターン

データベースコンポーネントの分解を評価する際によく見られる結合パターンがいくつかあります。これらのパターンを理解することは、適切に構造化されたデータベースコンポーネントを特定する上で不可欠です。このセクションでは、各パターン、その特性、および結合を強化するためのベストプラクティスについて説明します。

機能結合パターン

定義: すべての要素が 1 つの明確に定義された関数を直接サポートし、実行に貢献します。たとえば、支払い処理モジュール内のすべてのストアドプロシージャとテーブルは、支払い関連のオペレーションのみを処理します。

モダナイゼーションの影響: マイクロサービスデータベース設計に最適なパターン

課題:

結合を強化するためのベストプラクティス:

連続結合パターン

定義: ある要素からの出力は、別の要素の入力になります。たとえば、注文フィードの注文処理の検証結果などです。

モダナイゼーションの影響: 慎重なワークフロー分析とデータフローマッピングが必要

課題:

結合を強化するためのベストプラクティス:

コミュニケーションの結合パターン

定義: 要素は同じデータで動作します。たとえば、顧客プロファイル管理関数はすべて顧客データを使用します。

モダナイゼーションの影響: サービス分離のためのデータ境界を特定し、モジュール間の結合を減らすのに役立ちます

課題:

結合を強化するためのベストプラクティス:

手続き型結合パターン

定義: 要素は特定の順序で実行する必要があるため、グループ化されますが、機能的には関連しない場合があります。例えば、注文処理では、注文検証とユーザー通知の両方を処理するストアドプロシージャは、異なる目的を果たし、別々のサービスで処理できる場合でも、順番に行われるという理由だけでグループ化されます。

モダナイゼーションの影響: プロセスフローを維持しながら手順を慎重に分離する必要があります

課題:

結合を強化するためのベストプラクティス:

一時的な結合パターン

定義: 要素はタイミング要件によって関連しています。たとえば、注文が行われると、複数のオペレーションを一緒に実行する必要があります。一貫した注文状態を維持するためには、在庫チェック、支払い処理、注文確認、配送通知がすべて特定の時間枠内に行われる必要があります。

モダナイゼーションへの影響: 分散システムでは特別な処理が必要になる場合があります

課題:

結合を強化するためのベストプラクティス:

論理的または偶発的な結合パターン

定義: 要素は、関係が弱い、または意味のある関係がない場合でも、同じことを行うように論理的に分類されます。たとえば、顧客注文データ、倉庫在庫数、マーケティング E メールテンプレートは、アクセスパターン、ライフサイクル管理、スケーリング要件が異なるにもかかわらず、すべて販売オペレーションに関連しているため、同じデータベーススキーマに格納します。もう 1 つの例は、注文支払い処理と製品カタログ管理を同じデータベースコンポーネント内で組み合わせることです。どちらも e コマースシステムの一部であり、運用ニーズが異なる個別のビジネス機能を提供します。

モダナイゼーションの影響: リファクタリングまたは再編成が必要

課題:

結合を強化するためのベストプラクティス:

低結合と高結合の実装

ベストプラクティス

以下のベストプラクティスは、低い結合を実現するのに役立ちます。

以下のベストプラクティスは、高い結合を実現するのに役立ちます。

フェーズ 1: データの依存関係をマッピングする

データ関係をマッピングし、自然境界を特定します。などのツールを使用してSchemaSpy、エンティティ関係 (ER) 図でテーブルを表示することで、データベースを視覚化できます。これにより、データベースの静的分析が提供され、データベース内の明確な境界と依存関係の一部が示されます。

データベーススキーマは、グラフデータベースまたはJupiterノートブックでエクスポートすることもできます。次に、クラスタリングまたは相互接続されたコンポーネントアルゴリズムを適用して、自然境界と依存関係を特定できます。などの他の AWS Partner ツールはCAST Imaging、データベースの依存関係を理解するのに役立ちます。

フェーズ 2: トランザクションの境界とアクセスパターンを分析する

トランザクションパターンを分析して、アトミック性、一貫性、分離性、耐久性 (ACID) プロパティを維持し、データへのアクセス方法と変更方法を理解します。Oracle Automatic Workload Repository (AWR) や などのデータベース分析と診断ツールを使用できますPostgreSQL pg_stat_statements。この分析は、データベースにアクセスするユーザーとトランザクションの境界を理解するのに役立ちます。また、実行時にテーブル間の結合と結合を理解するのにも役立ちます。また、 などのコードとデータベース実行プロファイルをリンクできるモニタリングおよびプロファイリングツールを使用することもできますDynatrace AppEngine。

などの AI ツールは、アプリケーションの機能およびドメインの境界を分析することで、ドメインの境界を特定するvFunctionのに役立ちます。はvFunction主にアプリケーションレイヤーを分析しますが、そのインサイトはアプリケーションとデータベースの両方の分解を導き、ビジネスドメインとの整合性をサポートします。

フェーズ 3: 自己完結型テーブルを特定する

次の 2 つの主要な特性を示すテーブルを探します。

次の結合結合マトリックスは、各テーブルのデカップリングの難しさを特定するのに役立ちます。このマトリックスの右上に表示されているテーブルは、分離が最も簡単なため、最初のデカップリング作業の候補として最適です。ER 図では、これらのテーブルには外部キー関係やその他の依存関係はほとんどありません。これらのテーブルを切り離したら、より複雑な関係を持つテーブルに進みます。