注
現在、この機能はパブリック プレビュー段階にあります。 このプレビュー版はサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳細については、「Microsoft Azure プレビューの使用条件を参照してください。
グラフ データベースは、テーブルと行の代わりにノード (エンティティ) とエッジ (リレーションシップ) として情報を表すデータベースの一種です。 この構造により、データ全体の複雑な接続とパターンを簡単に調べることができます。
最も一般的に使用されるグラフ データベースの種類は、ラベル付きプロパティ グラフ (LPG) モデルを実装します。エンティティ (ノード) とリレーションシップ (エッジ) には、ラベルとプロパティ (キーと値のペア) を含めることができます。 この柔軟なモデルにより、スキーマオプションとスキーマ駆動設計の両方が可能になり、複雑なリレーションシップを表現できます。 接続はエッジとして明示的に格納されるため、クエリでは、クエリ時に高価な結合を計算するのではなく、エッジに従ってリレーションシップを走査します。
注
この記事の例では、 ソーシャル ネットワークのグラフ データセットの例を使用します。
Graph データベースのコア概念
グラフ データベースは、次の 3 つの基本的な構成要素にデータを整理します。
-
ノード は、人、製品、場所などのエンティティを表します。 ノードには、属性を記述するラベルとプロパティを含めることができます。 たとえば、
Personノードには、firstName、lastName、ageなどのプロパティが含まれます。 -
エッジ は、エンティティの接続方法 (
FRIENDS_WITH、PURCHASED、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 の人物ノードから出発し、:knows エッジに従って各フレンドノードへ進み、その後 :likes エッジに従って関連する :Comment ノードに進む。 作成日で並べ替えられたコメントの最新の 100 個を返します。
AI 支援グラフの推論 (プレビュー)
グラフ データベースは、言語モデルがマルチホップの質問に正確に回答するために必要な関係をエンコードするため、AI 推論に自然に適しています。 Microsoft Fabricでは、Fabric Data Agent はデータ ソースとしてグラフをサポートしており、ユーザーはグラフに対してクエリを実行してエージェントが回答する自然言語の質問を行えます。 NL2GQL が自然言語を GQL に変換する方法の詳細については、 Graph を利用した AI 推論のお知らせを参照してください。
グラフ データ モデルとスキーマの柔軟性
グラフ データ モデルはスキーマオプションです。柔軟なモデルから始めて、時間の経過と共に形式化することができます。 Microsoft Fabricのグラフでは、新しいプロパティの追加、ラベルの変更、リレーションシップの種類の変更などの構造的な変更では、現在、データを新しいモデルに再移行する必要があります。 このアプローチにより、データの重複の必要性が軽減され、チームは事前に大量の再設計を行うことなく、複数のソースからのデータを統合できます。 Microsoft Fabricのグラフで使用されるデータ モデルの詳細については、「Labeled プロパティ グラフを参照してください。
グラフ データベースの一般的な用途
グラフ データベースは、次のような接続が値を駆動するドメインと密接に連携します。
- ソーシャル ネットワーク - 人とその相互作用の間の関係をモデル化する
- ナレッジ グラフ - セマンティック検索と推論のための概念、エンティティ、ファクトを接続する
- レコメンデーション システム - ユーザー項目の対話をスキャンして、パーソナライズされた提案を表示する
- 不正アクセスとリスク ネットワーク - アカウント、トランザクション、デバイス間で疑わしいパターンを検出する
- ネットワークと IT トポロジ - サーバー、サービス、インフラストラクチャ コンポーネント間の依存関係をマップする
- サプライ チェーンの依存関係分析 - サプライヤー間のトレース コンポーネントの起源と関係
- グラフベースの取得拡張生成 (RAG) - 説明可能で根拠のある回答でマルチホップ推論を必要とする AI エージェントのナレッジ ソースとしてグラフ構造を使用する
これらのシナリオでは、個々のレコードについての質問が減り、複数のホップを介してどれだけのエンティティが関連し合い、相互作用するかが重要になります。
グラフ データベースを検討する場合
グラフ データベースは、リレーションシップが回答する必要がある主要な質問を推進する場合に適しています。 次の場合にグラフ データベースを選択します。
- 主な質問には、接続されたデータのパス、近隣、パターンが含まれます。
- ホップの数は可変であるか、事前に不明です。
- 異なるデータセット間でリレーションシップを結合して移動する必要があります。
このような質問を定期的に行う場合、グラフ モデルは自然に適合します。
Microsoft Fabricのグラフとスタンドアロン グラフ データベースの比較
データをグラフとして表し、別のスタンドアロン のグラフ データベースに格納すると、ETL (抽出、変換、読み込み) とガバナンスのオーバーヘッドが発生することがよくあります。 これに対し、Microsoft Fabricのグラフは OneLake で直接動作するため、個別の ETL パイプラインとデータ重複の必要性が軽減または排除されます。 次のトレードオフについて考えてみましょう。
- データ移動と重複: スタンドアロン グラフ データベースでは、通常、データを抽出、変換、および別のストアに読み込む必要があり、複雑さが増し、データセットが重複する可能性があります。 Graph は OneLake で動作するため、接続されたデータを移動せずにモデル化およびクエリを実行できます。
- 運用コスト: スタンドアロン グラフ スタックは個別のクラスターまたはサービスとして実行され、多くの場合、アイドル容量の料金が発生します。 グラフでは、ワークロードは、自動スケールダウンと一元化されたメトリックを使用してプールされた容量ユニット (CU) を使用します。これにより、運用が簡素化され、コストが削減されます。
- スケーラビリティ: 一部のスタンドアロン グラフ データベースは、スケールアップまたはベンダー固有のクラスタリングに依存します。 Graph は大規模なグラフ用に設計されており、複数のワーカー間でスケールアウト シャーディングを使用して、ビッグ データ ワークロードを効率的に処理します。
- ツールとスキル: ベンダー固有のグラフ システムには、特殊な言語と個別の分析フレームワークが必要な場合があります。 Graph では、統合モデリング、標準ベースのクエリ (GQL)、組み込みのグラフ分析アルゴリズム、BI と AI の統合、Fabric Data Agent を含む 自然言語グラフクエリ (プレビュー) のサポート、そしてローコード/ノーコード探索ツールが提供されます。 これらの機能を使用すると、より広範なユーザーが接続されたデータを操作できます。
- ガバナンスとセキュリティ: 個別のグラフ展開には、独立したガバナンスとセキュリティのセットアップが必要です。 Graph では OneLake ガバナンス、系列、ワークスペースのロールベースのアクセス制御 (RBAC) が使用されるため、コンプライアンス、監査、アクセス許可は、Fabric環境の残りの部分と一貫性を保ちます。