次の方法で共有


グラフ データベースとは

現在、この機能はパブリック プレビュー段階にあります。 このプレビュー版はサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳細については、「Microsoft Azure プレビューの使用条件を参照してください。

グラフ データベースは、接続されたデータをモデル化してクエリを実行する強力な方法を提供します。 テーブルにデータを格納する従来のリレーショナル データベースとは異なり、グラフ データベースは情報をノード (エンティティ) とエッジ (リレーションシップ) として表し、複雑な接続やパターンをより柔軟に探索しやすくします。 この記事では、グラフ データベースの主要な概念、グラフ クエリのしくみ、ワークロードにグラフ データベースを使用することを検討するタイミングの概要について説明します。 また、Fabric Graph とスタンドアロン グラフ データベースのデプロイを比較します。

最も一般的に使用されるグラフ データベースの種類は、 ラベル付きプロパティ グラフ (LPG) モデルを実装します。エンティティ (ノード) とリレーションシップ (エッジ) には、ラベルとプロパティ (キーと値のペア) を含めることができます。 この柔軟なモデルにより、スキーマオプションとスキーマ駆動設計の両方が可能になり、豊富なセマンティクスを表現できます。 接続はエッジとして明示的に格納されるため、クエリでは、クエリ時に高価な結合を計算するのではなく、エッジに従ってリレーションシップを走査します。

Important

この記事では、 ソーシャル ネットワークのグラフ データセットの例のみを使用します。

Graph データベースのコア概念

  • ノード は、人、製品、場所などのエンティティを表します。 ノードには、属性を記述するラベルとプロパティを含めることができます。 たとえば、Person ノードには、firstName、lastName、age などのプロパティが含まれます。
  • エッジ は、エンティティの接続方法 (FRIENDS_WITH、購入済み、LOCATED_INなど) を表します。 エッジには、リレーションシップ メタデータをエンコードするためのプロパティとラベルを含めることもできます。
  • プロパティは 、ノードとエッジに詳細をアタッチします (たとえば、ユーザーの名前や日付以降のエッジ)。 リレーションシップはエッジとして明示的に格納されるため、クエリでは、クエリ時に計算するのではなく、接続に従ってグラフ内を移動します。

リレーションシップのクエリのしくみ

グラフ クエリでは、開始ノードから近隣ノード、その近隣ノードなどへ走査することで、接続された情報を取得します。 トラバーサルが実行する作業は、データセットの合計サイズではなく、タッチするエッジの数 (ローカル近傍) に関連付けられています。 この特性により、 友人の友人、最短パス、マルチホップの依存関係など、パス、接続、パターンに関する質問が自然で効率的に表現されます。

グラフ データベースでは、ますます採用される Graph クエリ言語 (GQL) などのパターンベースのクエリ言語を使用して、これらのトラバーサルを簡潔に記述します。 SQL (ISO/IEC 39075) を監督する同じ国際作業グループは、グラフ クエリを確立されたデータベース標準に合わせて調整する GQL を標準化しています。

例 (GQL でのパターン マッチング):

MATCH (p:Person {firstName: "Annemarie"})-[:knows]->(friend)-[:likes]->(c:Comment)
RETURN c
ORDER BY c.creationDate
LIMIT 100

このパターンは次のように解釈します: Annemarie の人物ノードから出発し、 エッジに従って各フレンドノードへ進み、その後 エッジに従って関連する ノードに進む。 作成日で並べ替えられたコメントの最新の 100 個を返します。

モデリングとスキーマ

グラフ データ モデルはスキーマオプションです。強力なガバナンスが必要な場合は、固定スキーマを操作したり、新しいノードの種類、リレーションシップ、またはプロパティが表示されたときにモデルを進化させることができます。 このアプローチにより、データの重複の必要性が軽減され、チームは事前に大量の再設計を行うことなく、複数のソースからのデータを統合できます。

グラフ データベースの一般的な用途

グラフ データベースは、次のような接続が値を駆動するドメインと密接に連携します。

  • ソーシャル ネットワーク
  • ナレッジ グラフ
  • レコメンデーション システム
  • 不正行為とリスク ネットワーク
  • ネットワークと IT トポロジ
  • サプライ チェーンの依存関係分析

これらのシナリオでは、個々のレコードについての質問が減り、複数のホップを介してどれだけのエンティティが関連し合い、相互作用するかが重要になります。

グラフ データベースを検討する場合

次の場合にグラフ データベースを選択します。

  • 主な質問には、接続されたデータのパス、近隣、パターンが含まれます。
  • ホップの数は可変であるか、事前に不明です。
  • 異なるデータセット間でリレーションシップを結合して移動する必要があります。

このような質問を定期的に行う場合、グラフ モデルは自然に適合します。

Fabric Graph とスタンドアロン グラフ データベースの比較

データをグラフとして表し、別のスタンドアロン のグラフ データベースに格納すると、ETL (抽出、変換、読み込み) とガバナンスのオーバーヘッドが発生することがよくあります。 これに対し、Graph は OneLake で直接動作するため、個別の ETL パイプラインとデータ重複の必要性が軽減または排除されます。 次のトレードオフについて考えてみましょう。

  • データ移動と重複: スタンドアロン グラフ データベースでは、通常、データを抽出、変換、および別のストアに読み込む必要があり、複雑さが増し、データセットが重複する可能性があります。 Graph は OneLake で動作するため、接続されたデータを移動せずにモデル化およびクエリを実行できます。
  • 運用コスト: スタンドアロン グラフ スタックは個別のクラスターまたはサービスとして実行され、多くの場合、アイドル容量の料金が発生します。 Graph の Graph ワークロードは、自動スケールダウンと一元化されたメトリックを使用してプールされた容量ユニット (CU) を使用します。これにより、操作が簡素化され、コストが削減されます。
  • スケーラビリティ: 一部のスタンドアロン グラフ データベースは、スケールアップまたはベンダー固有のクラスタリングに依存します。 Graph は大規模なグラフ用に設計されており、複数のワーカー間でスケールアウト シャーディングを使用して、ビッグ データ ワークロードを効率的に処理します。
  • ツールとスキル: ベンダー固有のグラフ システムには、特殊な言語と個別の分析フレームワークが必要な場合があります。 Graph には、統合モデリング、標準ベースのクエリ (GQL)、組み込みのグラフ分析アルゴリズム、BI、AI 統合、およびロー/ノー コード探索ツールが用意されています。 これらの機能を使用すると、より広範なユーザーが接続されたデータを操作できます。
  • ガバナンスとセキュリティ: 個別のグラフ展開には、独立したガバナンスとセキュリティのセットアップが必要です。 Graph では、OneLake のガバナンス、系列、ワークスペースのロールベースのアクセス制御 (RBAC) が使用されるため、コンプライアンス、監査、アクセス許可は Fabric 環境の残りの部分と一貫性を保ちます。