Azure Cosmos DB for Apache Gremlin を使用したグラフ データ モデリング
適用対象: 
Gremlin
この記事では、グラフ データ モデルの使用に関する推奨事項を示します。 これらのベスト プラクティスは、データの進化に合わせてグラフ データベース システムのスケーラビリティとパフォーマンスを確保するために不可欠です。 効率的なデータ モデルは、大規模なグラフで特に重要です。
必要条件
このガイドに記載されているプロセスは、次の前提条件に基づいています。
- 問題空間内のエンティティが特定されている。 これらのエンティティは各要求に対して "アトミックに" 使用されます。 つまり、このデータベース システムは複数のクエリ要求で 1 つのエンティティのデータを取得するようには設計されていません。
- このデータベース システムの "読み取りと書き込みの要件" を理解している。 これらの要件は、グラフ データ モデルに必要な最適化の指針となります。
- Apache Tinkerpop プロパティ グラフ標準の原則について十分に理解している。
グラフ データベースが必要になる場合
データ ドメイン内のエンティティとリレーションシップが次のいずれかの特性を備えている場合に、グラフ データベース ソリューションを最適に使用できます。
- エンティティが、わかりやすいリレーションシップにより緊密に接続されている。 このシナリオのメリットは、リレーションシップがストレージ内に保持されることです。
- 循環リレーションシップまたは自己参照エンティティがある。 このパターンは、リレーショナルまたはドキュメント データベースを使用する場合に課題となることがよくあります。
- エンティティ間に動的に発展するリレーションシップがある。 このパターンは、多数のレベルがある階層またはツリー構造のデータに特に適用されます。
- エンティティ間に多対多のリレーションシップがある。
- エンティティとリレーションシップの両方に書き込みと読み取りの要件がある。
上記の条件を満たしている場合、グラフ データベースのアプローチが "クエリの複雑さ"、"データ モデルのスケーラビリティ"、および "クエリ パフォーマンス" の面でメリットをもたらす可能性があります。
次の手順では、分析とトランザクション目的のどちらでグラフを使用するかを確認します。 グラフが高負荷な計算やデータ処理のワークロードに使用される場合は、Cosmos DB Spark コネクタや GraphX ライブラリについて検討する価値があります。
グラフ オブジェクトを使用する方法
Apache Tinkerpop プロパティ グラフ標準では、2 種類のオブジェクト Vertex と Edge が定義されています。
グラフ オブジェクトのプロパティのベスト プラクティスを以下に示します。
| Object | プロパティ | Type | Notes |
|---|---|---|---|
| Vertex | id | String | パーティションごとに一意に適用されます。 挿入時に値が指定されていない場合、自動生成された GUID が格納されます。 |
| Vertex | Label | String | このプロパティは、頂点が表すエンティティの種類を定義するために使用されます。 値が指定されないと、既定値の vertex が使用されます。 |
| Vertex | プロパティ | 文字列、ブール値、数値 | 各頂点にキーと値のペアとして格納される個々のプロパティの一覧。 |
| Vertex | パーティション キー | 文字列、ブール値、数値 | このプロパティでは、頂点とその外向きエッジを格納する場所を定義します。 グラフのパーティション分割の詳細をご覧ください。 |
| Edge | id | String | パーティションごとに一意に適用されます。 既定で自動生成されます。 エッジは、通常、ID によって一意に取得する必要がありません。 |
| Edge | Label | String | このプロパティは、2 つの頂点のリレーションシップの種類を定義するために使用されます。 |
| Edge | プロパティ | 文字列、ブール値、数値 | 各エッジにキーと値のペアとして格納される個々のプロパティの一覧。 |
Note
エッジにはパーティション キー値が必要ありません。その値はそのソースとなる頂点に基づいて自動的に割り当てられるためです。 詳細については、「Azure Cosmos DB でのパーティション分割されたグラフの使用」を参照してください。
エンティティとリレーションシップのモデリングのガイドライン
以下のガイドラインは、Azure Cosmos DB for Apache Gremlin グラフ データベースのデータ モデリングにアプローチする際に役立ちます。 これらのガイドラインでは、データ ドメインとそのクエリの既存の定義があることを前提としています。
Note
以下の手順は、推奨事項として示されています。 最終的なモデルを評価およびテストしてから、運用環境に対応できると見なす必要があります。 さらに、これらの推奨事項は、Azure Cosmos DB の Gremlin API の実装に固有です。
頂点とプロパティのモデル化
グラフ データ モデルの最初の手順では、識別されたすべてのエンティティを Vertex オブジェクトにマップします。 すべてのエンティティと頂点の 1 対 1 のマッピングは、最初の手順であり、変更されることがあります。
よくある落とし穴の 1 つとして、1 つのエンティティのプロパティを別々の頂点としてマップすることがあります。 同じエンティティを 2 つの異なる方法で表現する次の例について考えてみましょう。
頂点に基づくプロパティ:このアプローチでは、エンティティは 3 つの個別の頂点と 2 つのエッジを使用して、そのプロパティを記述します。 このアプローチにより、冗長性が軽減される可能性はありますが、モデルの複雑さが増します。 モデルの複雑さが増すと、待ち時間、クエリの複雑さ、および計算コストが増加する場合があります。 このモデルでは、パーティション分割で問題が発生する可能性もあります。
プロパティが埋め込まれた頂点:このアプローチでは、キーと値のペアの一覧を利用して、頂点内でエンティティのすべてのプロパティを表します。 このアプローチでは、モデルの複雑さが軽減され、クエリがシンプルになり、トラバーサルのコスト効率が高くなります。
注意
上記の図では、エンティティのプロパティを分割する 2 つの方法を比較する簡略化されたグラフ モデルを示しています。
プロパティが埋め込まれた頂点パターンは、一般に、パフォーマンスとスケーラビリティの高いアプローチを提供します。 新しいグラフ データ モデルに対する既定のアプローチは、このパターンになる傾向があります。
ただし、プロパティの参照がメリットをもたらすことがあるシナリオもあります。 たとえば、参照されるプロパティが頻繁に更新される場合です。 個々の頂点を使用して、繰り返し変更されるプロパティを表すことで、更新に必要な書き込み操作の量が最小限に抑えられます。
エッジの方向によるリレーションシップのモデル
頂点をモデル化した後、それらのリレーションシップを示すためにエッジを追加できます。 評価する必要がある最初の側面は、リレーションシップの方向です。
Edge オブジェクトには、out() または outE() 関数を使用した場合にトラバーサルが従う既定の方向があります。 すべての頂点はその外向きエッジと共に格納されるため、この自然な方向を使用すると、効率的な操作になります。
ただし、in() 関数を使用してエッジの反対方向にトラバースすると、必ずクロスパーティション クエリになります。 詳しくは、グラフのパーティション分割に関する記事をご覧ください。 絶えず in() 関数を使用してトラバースする必要がある場合、両方向にエッジを追加することをお勧めします。
エッジの方向を指定するには、.addE() Gremlin ステップに .to() または .from() 述語を使用します。 または、Gremlin API 用 bulk executor ライブラリを使用します。
Note
Edge オブジェクトには、既定で方向があります。
リレーションシップのラベル
わかりやすいリレーションシップ ラベルを使用すると、エッジ解決操作の効率を向上させることができます。 このパターンを次の方法で適用できます。
- 一般的でない用語を使用して、リレーションシップにラベルを付ける。
- リレーションシップ名を使用して、ソースの頂点のラベルとターゲットの頂点のラベルを関連付ける。
トラバーサーがエッジのフィルター処理に使用するラベルを具体的にするほど良くなります。 この決定は、クエリのコストにも大きな影響を与える可能性があります。 クエリのコストは、executionProfile ステップを使用していつでも評価できます。
次のステップ
- サポートされている Gremlin ステップの一覧を確認する。
- 大規模なグラフを扱うためにグラフ データベースのパーティション分割について確認する。
- 実行プロファイル ステップを使用して Gremlin クエリを評価する。
- サードパーティ製グラフのデータ モデルの設計。