注
現在、この機能はパブリック プレビュー段階にあります。 このプレビュー版はサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳細については、「 Microsoft Azure プレビューの追加使用条件」を参照してください。
グラフ データベースは、接続されたデータをモデル化してクエリを実行する強力な方法を提供します。 テーブルにデータを格納する従来のリレーショナル データベースとは異なり、グラフ データベースは情報をノード (エンティティ) とエッジ (リレーションシップ) として表し、複雑な接続やパターンをより柔軟に探索しやすくします。
最も一般的に使用されるグラフ データベースの種類は、 ラベル付きプロパティ グラフ (LPG) モデルを実装します。エンティティ (ノード) とリレーションシップ (エッジ) には、ラベルとプロパティ (キーと値のペア) を含めることができます。 この柔軟なモデルにより、スキーマオプションとスキーマ駆動設計の両方が可能になり、豊富なセマンティクスを表現できます。 接続はエッジとして明示的に格納されるため、クエリでは、クエリ時に高価な結合を計算するのではなく、エッジに従ってリレーションシップを走査します。
Important
この記事では、 ソーシャル ネットワークのグラフ データセットの例のみを使用します。
Graph データベースのコア概念
- ノード は、人、製品、場所などのエンティティを表します。 ノードには、属性を記述するラベルとプロパティを含めることができます。 たとえば、Person ノードには、firstName、lastName、age などのプロパティが含まれます。
- エッジ は、エンティティの接続方法 (FRIENDS_WITH、購入済み、LOCATED_INなど) を表します。 エッジには、リレーションシップ メタデータをエンコードするためのプロパティとラベルを含めることもできます。
- プロパティは 、ノードとエッジに詳細をアタッチします (たとえば、ユーザーの名前や日付以降のエッジ)。 リレーションシップはエッジとして明示的に格納されるため、クエリでは、クエリ時に計算するのではなく、接続に従ってグラフ内を移動します。
リレーションシップのクエリのしくみ
グラフ クエリでは、開始ノードから近隣ノード、その近隣ノードなどへ走査することで、接続された情報を取得します。 トラバーサルが実行する作業は、データセットの合計サイズではなく、タッチするエッジの数 (ローカル近傍) に関連付けられています。 これにより、 友人の友人、最短パス、マルチホップの依存関係など、パス、接続、パターンに関する質問が自然で効率的に表現できます。
グラフ データベースでは、ますます採用される Graph クエリ言語 (GQL) などのパターンベースのクエリ言語を使用して、これらのトラバーサルを簡潔に記述します。 GQL は、SQL (ISO/IEC 39075) を監督する同じ国際的な作業グループによって標準化されており、グラフ クエリは確立されたデータベース標準に合わせて調整されています。
例 (GQL でのパターン マッチング):
MATCH (p:Person {firstName: "Annemarie"})-[:knows]->(friend)-[:likes]->(c:Comment)
RETURN c
ORDER BY c.creationDate
LIMIT 100
このパターンは次のように解釈します: Annemarie の人物ノードから出発し、:knows エッジに従って各フレンドノードへ進み、その後 :likes エッジに従って関連する :Comment ノードに進む。 作成日で並べ替えられたコメントの最新の 100 個を返します。
モデリングとスキーマ
グラフ データ モデルはスキーマオプションです。強力なガバナンスが必要な場合は、固定スキーマを操作したり、新しいノードの種類、リレーションシップ、またはプロパティが表示されたときにモデルを進化させることができます。 このアプローチにより、データの重複の必要性が軽減され、チームは事前に大量の再設計を行うことなく、複数のソースからのデータを統合できます。
グラフ データベースの一般的な用途
グラフ データベースは、次のような接続が値を駆動するドメインと密接に連携します。
- ソーシャル ネットワーク
- ナレッジ グラフ
- レコメンデーション システム
- 不正行為とリスク ネットワーク
- ネットワークと IT トポロジ
- サプライ チェーンの依存関係分析
これらのシナリオでは、個々のレコードについての質問が減り、複数のホップを介してどれだけのエンティティが関連し合い、相互作用するかが重要になります。
グラフ データベースを検討する場合
次の場合にグラフ データベースを選択します。
- 主な質問には、接続されたデータのパス、近隣、パターンが含まれます
- ホップの数が可変であるか、事前に不明です
- 異なるデータセット間でリレーションシップを結合して移動する必要がある
このような質問を定期的に行う場合、グラフ モデルは自然に適合します。
Microsoft Fabric のグラフ
データをグラフとして表し、別のスタンドアロン のグラフ データベースに格納すると、ETL (抽出、変換、読み込み) とガバナンスのオーバーヘッドが発生することがよくあります。 対照的に、Microsoft Fabric の Graph は OneLake で直接動作するため、個別の ETL パイプラインとデータ重複の必要性が軽減または排除されます。 次のトレードオフについて考えてみましょう。
- データ移動と重複: スタンドアロン グラフ データベースでは、通常、データを抽出、変換、および別のストアに読み込む必要があり、複雑さが増し、データセットが重複する可能性があります。 Microsoft Fabric の Graph は OneLake で動作するため、接続されたデータを移動せずにモデル化およびクエリを実行できます。
- 運用コスト: スタンドアロン グラフ スタックは個別のクラスターまたはサービスとして実行され、多くの場合、アイドル容量の料金が発生します。 Fabric のグラフ ワークロードは、自動スケールダウンと一元化されたメトリックを使用してプールされた容量ユニット (CU) を使用します。これにより、操作が簡素化され、コストが削減されます。
- スケーラビリティ: 一部のスタンドアロン グラフ データベースは、スケールアップまたはベンダー固有のクラスタリングに依存します。 Microsoft Fabric の Graph は、大規模なグラフ向けに設計されており、複数のワーカー間でスケールアウト シャーディングを使用して、ビッグ データ ワークロードを効率的に処理します。
- ツールとスキル: ベンダー固有のグラフ システムには、特殊な言語と個別の分析フレームワークが必要な場合があります。 Microsoft Fabric の Graph には、統合モデリング、標準ベースのクエリ (GQL)、組み込みのグラフ分析アルゴリズム、BI と AI の統合、およびロー/ノー コード探索ツールが用意されています。 これらの機能を使用すると、より広範なユーザーが接続されたデータを操作できます。
- ガバナンスとセキュリティ: 個別のグラフ展開には、独立したガバナンスとセキュリティのセットアップが必要です。 Microsoft Fabric の Graph では、OneLake のガバナンス、系列、ワークスペースのロールベースのアクセス制御 (RBAC) が使用されるため、コンプライアンス、監査、アクセス許可は Fabric 環境の残りの部分と一貫性を保ちます。