https://www.yangdb.org/
ウィキ
バージョン情報
リリースノート
リオール・ペリー
ローマン・マルゴリス
モティ・コーエン
エラド・ヴィース
シモン・ベノシュティ
Opensearch 上でスケーラブルな分散グラフ DB を構築するための新しいオープンソース イニシアチブを紹介する投稿 https://www.linkedin.com/pulse/making-db-lior-perry/
グラフ DB としての Opensearch の別の使用法 https://medium.com/@imriqwe/elasticsearch-as-a-graph-database-bc0eee7f7622
グラフ データベースの世界は、ここ数年、特にソーシャル ネットワークとその日常活動への影響に多大な影響を与えてきました。
かつては強力な (そして孤独な) RDBMS でしたが、現在では、データ センター内に新たに登場し、ますます重要性を増しているパートナーであるグラフ データベースのためにスペースを確保する必要があります。
Twitter も Facebook も使用しており、オンラインの出会い系サイトでも使用されています。彼らは関係グラフを使用しています。結局のところ、ソーシャルはソーシャルであり、結局のところ、すべては人間関係に関するものなのです。
グラフ テクノロジーを区別する 2 つの主な要素は、ストレージと処理です。
グラフ ストレージは通常、グラフ データを含むデータベースの構造を指します。
このようなグラフ ストレージは、多くの側面でグラフ用に最適化されており、データが効率的に保存され、実際の物理層でノードと関係が互いに近くに保たれます。
ストレージがリレーショナル、カラム型、またはその他のタイプのデータベースなどの外部ソースから取得される場合、グラフ ストレージは非ネイティブとして分類されます (ほとんどの場合、NoSQL ストアが推奨されます)。
非ネイティブ グラフ データベースは通常、グラフ データ モデルのクエリ シナリオに適合した既存のリレーショナル ストア、ドキュメント ストア、およびキー値ストアで構成されます。
グラフ処理には、グラフへのアクセス、頂点とエッジの走査、結果の収集が含まれます。
トラバーサルとは、グラフをクエリする方法であり、開始ノードから関連ノードに移動し、いくつかのルールに従って関係をたどります。
「友達が好きで、私がまだ持っていない音楽は何ですか?」などの質問に対する答えを見つけることができます。
グラフを表現するための最も一般的なモデルの 1 つは、プロパティ モデルです。
このモデルには、任意の数の属性 (キーと値のペア) を保持できる接続されたエンティティ (ノード) が含まれています。
ノードには一意の ID があり、属性のリストはその機能とコンテンツを表します。
ノードには、ドメイン内でのさまざまな役割を表すラベルを付けることができます。関係プロパティに加えて、ラベルはグラフ要素のメタデータを提供することもできます。
ノードはエンティティを表すためによく使用されますが、ドメインによっては、その目的にも関係が使用される場合があります。
関係は、接続しているソース ノードとターゲット ノードによって表され、同じ頂点間に複数の接続がある場合は、区別するためのプロパティの追加ラベル (関係のタイプ)
リレーションシップはノードを任意の構造に編成し、グラフをリスト、ツリー、マップ、または複合エンティティに似せることができます。これらはいずれもさらに複雑な構造に結合できます。
リレーショナル DB モデルのテーブル間の外部キーと非常によく似ており、グラフ モデルでは、リレーションシップは頂点間の関係を記述します。
このモデルの (厳密なリレーショナル スキーマと比較した) 大きな違いの 1 つは、このスキーマのない構造により、制約なしで頂点間の関係を追加/削除できることです。
追加のグラフ モデルは、リソース記述フレームワーク (RDF) モデルです。
私たちのユースケースはソーシャル ネットワークの領域にあります。頻繁に更新し、次の両方で利用できる必要がある非常に大規模なソーシャル グラフ。
単純な (ほとんどがテキストによる) 検索
グラフベースのクエリ。
すべての読み取りと書き込みは並行して行われ、妥当な応答時間と増加し続けるスループットを実現します。
最初の要件は、非常に大量のデータを含めることができる、よく知られ確立された NoSql ドキュメント検索およびストレージ エンジンである Opensearch を使用して満たされました。
2 番目の要件については、Opensearch を非ネイティブ グラフ DB ストレージ レイヤーとして使用することが最善の解決策であると判断しました。
前述したように、グラフ DB ストレージ レイヤーは、NoSql ストレージなどの非ネイティブ ストレージを使用して実装できます。
今後の議論では、グラフ DB のコミュニティで最も人気のある代替手段である Neo4J がなぜ私たちのニーズに適合しないのかについて詳しく説明します。
最初の課題は、グラフを頂点と辺のセットとして表すデータ モデルを設計することです。
Opensearch を使用すると、その強力な検索機能を利用して、クエリ フィルターに従ってノードとリレーションのドキュメントを効率的にフェッチできます。
Opensearch では、各インデックスを特定のスキーマのテーブルとして記述することができ、インデックス自体は共有に分割され、クラスター全体での拡張性と (レプリカによる) 冗長性が可能になります。
ドキュメントは、次の式を使用してインデックス内の特定のシャードにルーティングされます。
shard_num = ハッシュ(_routing) % num_primary_shards
各インデックスには、ドキュメントの構造 (Opensearch ではマッピングと呼ばれます) を定義するスキーマ (Opensearch ではタイプと呼ばれます) があります。各インデックスは単一タイプのマッピングのみを保持できます (Opensearch 6 以降)
頂点インデックスにはプロパティを持つ頂点ドキュメントが含まれ、エッジ インデックスにはプロパティを持つエッジ ドキュメントが含まれます。
グラフ (データ ソース) を移動する方法を記述する方法
グラフ指向のクエリ言語はいくつかあります。
Cypher は Neo4j グラフ データベースのクエリ言語です (openCypher イニシアチブを参照)
Gremlin は、OLTP および OLAP グラフ システム用の Apache Software Foundation グラフ トラバーサル言語です。
SPARQL は、RDF グラフ用のクエリ言語です。
言語の中には、よりパターンベースで宣言型のものもあれば、命令型のものもあります。それらはすべて、データを走査する論理的な方法を記述しています。
Cypher について考えてみましょう。Cypher は、アスキーアート構文を使用してグラフ内のパターンを視覚的に記述するための、SQL にインスピレーションを得た宣言型言語です。
これにより、グラフ データから何を選択、挿入、更新、または削除するかを、その方法を正確に説明することなく指定できます。
論理クエリが与えられたら、それをデータ ストレージの物理層 (Opensearch) に変換する必要があります。
Opensearch には、検索と集計に焦点を当てたクエリ DSL があります。トラバースではなく、グラフ (および基礎となるインデックス) の概略構造を考慮する追加の変換フェーズが必要です。
論理クエリから物理クエリへの変換は、いくつかの手順を含むプロセスです。
スキーマに対してクエリを検証する
ラベルを実際のスキーマ エンティティ (インデックス) に変換する
物理的な Opensearch クエリの作成
これは、実際には、高レベルのレビューのプロセスです。論理クエリを最適化するためのさらに多くの段階があります。場合によっては、複数の物理プラン (実行プラン) を作成し、フェッチに必要な要素の数などの効率 (コスト) 戦略に従ってそれらをランク付けすることができます。
私たちは、今日のビジネスユースケースにおけるグラフ DB の目的について議論することから始め、グラフを表現するためのさまざまなモデルを検討しました。潜在的なグラフ DB が構成すべき基本的な論理構成要素を理解し、ストレージ層の要件を満たす既存の NoSql 候補について説明しました。
ストレージ レイヤーとして Opensearch を選択した後、LDBC ソーシャル ネットワーク ベンチマーク グラフ モデルを採用し、その特定のストレージで最適化されるように単純化しました。冗長プロパティを備えた実際のストレージ スキーマについて説明し、SQL のようなグラフ パターン言語でストレージをクエリするための暗号言語を検討しました。
私たちは引き続き、暗号クエリが Opensearch によって実行される物理的な実行クエリに実際に変換される様子を確認しました。
最後のセクションでは、単純なグラフ クエリを取り上げ、実行戦略とバルキング メカニズムの詳細を掘り下げました。
インストールチュートリアル:
スキーマ作成チュートリアル:
データ読み込みチュートリアル:
グラフのクエリのチュートリアル:
投影の実体化とカウントのチュートリアル: