この記事には次の内容が含まれます。
· データベースの主な技術分類
· グラフとは何ですか?
· グラフ パターン
· グラフ データベース VS. リレーショナル データベース
· グラフ データベース VS. 他の NOSQL の比較
· すべてのグラフ データベースが同じというわけではありません。
Gartner の予測によると、「2025 年までに、グラフ テクノロジーを使用したデータと分析のイノベーションの割合は 2021 年の 10% から 80% に増加し、企業の迅速な意思決定が大幅に促進されるでしょう。」
上の図は、データベースの主な技術トラックを著者が簡単に分類したものです。以前の記事 [Ying Figure | データベース開発のマイルストーンを理解するには 1 つの記事?]と組み合わせることもできます。- Zhihu (zhihu.com) ] 一緒に見ましょう。データベース技術の 50 年を超える開発の歴史の中で、その旺盛な活力と、新しいデータベースが従来のデータベースにもたらす課題を見つけるのは難しくありません。その背後にある主な要因は、新しく効率的なデータベースに対する緊急の必要性です。産学においては、データ量（ボリューム）の急速な増大、データ種類の多様性（ボリューム）、データ生成速度（ボリューム）の急速な高速化、社会の注目を集める柔軟な高次元アーキテクチャが登場しています。データの価値 (ボリューム) ——1983 年以来、GQL が SQL に次ぐ唯一の国際標準となった理由がわかります。このことは、グラフ データベース テクノロジーが将来に与える影響と重要性を強く示しています。
表 1: 5 種類の主流データベース製品の分析
| 分類 |
パフォーマンス |
スケーラビリティ |
柔軟性 |
複雑 |
| キー値格納データベース |
高い |
高い |
高い |
なし |
| 文書データベース |
高い |
変数 |
高い |
低い |
| カラムストアデータベース |
高い |
変数 |
一般的に |
低い |
| グラフデータベース |
変数 |
高い |
高い |
高い |
| リレーショナルデータベース |
変数 |
変数 |
低い |
一般的に |
Graph Database は、グラフ理論に基づいて実装された NoSQL データベースであり、エンティティの属性情報とエンティティ間の関係情報を格納でき、シンプルなモデリング、強力なパフォーマンス、豊富な検索機能、および強力な拡張性を備えています。
グラフは、頂点と、頂点の各ペアを接続するエッジで構成されます。
点（ノード）：頂点（Vertex）または点（ノード）と呼ばれ、実体（Entity）とも呼ばれます。
エッジ: 2 つの点 (ノード) を結ぶエッジであり、ナレッジ グラフのカテゴリではリレーションシップ (関係、関係) と呼ばれることもあります。
たとえば、レオナルド・ダ・ヴィンチとルーヴル美術館の関係を調べると、人と物体との間の非常に単純な図を関連付けることができます。この図から生まれたのが「6 次の分離理論」です。
もう一つの例は、私たちが日常生活でほぼ毎日使用する通勤手段である地下鉄です。駅を「点」とみなして、隣り合う2つの駅を「辺」で結ぶと、これも一般的な「グラフ」で結ぶことができます。
私たちは自分自身の思考で無限に拡張することができ、ノードとノードを接続することで、指先でグラフ データを通じて現実世界の属性や関係を直接構築できます [詳細については、ライブラリを参照 | グラフとは何ですか? 】。
グラフ モードには、属性グラフ、ハイパーグラフ、トリプレットの 3 種類があります。これは、グラフ データを最終的に特定のデータ ファイルに実装する前に、特定のグラフ データベースに保存する必要があり、このプロセスには当然、どのような実装方法が使用されるかが含まれます。グラフデータを保存します。Ultipa Graph を例に挙げると、Nejo4 と同様、プロパティ グラフ (プロパティ グラフ) です - プロパティ グラフ モデルは理解しやすく、ほとんどのグラフ使用シナリオを説明できます。
なぜグラフデータベースの利点がますます顕著になっているのでしょうか? たとえば、従来のリレーショナル データベースでは、複数のテーブルの相関クエリが含まれると、テーブル内のデータ量のデカルト積に比例して計算量が増加します。データ量が増えると、テーブルの相関も増加し、より複雑になり、効率が低下します。これは、外部キーを使用してメイン テーブル内で一致する主キー レコードを検索し、検索および一致計算操作を実行するためです。多対多のリレーションシップが使用される場合は、参加する 2 つの関係間の外部キーの対応を保存するために中間テーブルを追加する必要があります。これにより、結合操作のコストがさらに増加します。
グラフ データベースは非常に柔軟で、人々の生地データ間の関係を点とエッジを通じて簡潔に示すことができるだけでなく、使用される計算ロジックには、計算量が少なく、効率が飛躍的に向上する最近傍相関計算 (クエリ) モードが使用されます。 。下の写真を参照してください。
たとえば、リレーショナル データベースとグラフ データベースを使用してレイヤー 2 から 5 までの深い浸透を行う場合、パフォーマンスの差は実際には指数関数的に増加します。たとえば、レイヤー 1 の浸透を実行する場合、この 2 つに本質的な違いはないかもしれませんが、レイヤー 2 から開始すると、指数関数的 (10 倍以上) の変化が発生し、結果を返すことができなくなります。マシンの計算範囲を超えたため、停止しました。(興味のある読者は、グラフ データベースとリレーショナル データベースの違いを詳しく読んでください⁴ )。
現在の主要なデータベースの市場シェアから判断すると、依然としてリレーショナルデータベースが主流ですが、これは過去に代替手段が不足していた時代の背景であり、それが成り立たないシナリオが増えている中で、グラフデータベースがその役割を担っています。生まれつきの遺伝的優位性は、コーナーでの追い越しの武器となるだろう。
表 2: 主流のグラフ データベースの比較
| Nejo4j |
ヤヌスグラフ |
アルティパグラフ |
|
| 評判 |
最高 |
高い |
一般的に |
| オープンソースエコシステム |
コミュニティ バージョンはオープン ソースですが、より多くの制限があります。商用バージョンはクローズ ソースです。 |
オープンソース; Apache Tinkerpop エコシステムと互換性があり、主に AWS および IBM が提供するクラウド サービス |
クローズドソースのクラウドサービスは主にUltipa Cloudが提供 |
| グラフクエリ言語 |
サイファー |
グレムリン |
UQL |
| サポートデータスケール |
コミュニティ バージョンは 10 億レベルで評価され、エンタープライズ バージョンは 1,000 億レベル以上で評価されます |
百億レベル以上 |
1000億レベル以上 |
| 大規模データ書き込み性能 |
オンラインインポートが遅い |
もっとゆっくり |
高速オンラインインポート |
| 大規模なデータクエリのパフォーマンス |
高速かつより安定した |
もっと早く |
高速かつ超安定 |
| 機能的にも完璧 |
完了 |
完了 |
完了 |
| データインポートツール |
CSV オンラインインポートをサポート、リッチフォーマットをサポート |
サポートは提供されません |
Ultipa Transporter は、すべてのプラットフォームでの実行をサポートし、さまざまな形式をサポートし、TSV、CSV、Mysql、BigQuery などのファイルのデータ インポート機能と CSV エクスポート機能を提供します。 |
| ビジュアルインターフェイス |
サポート、豊富な機能、ビジュアルデータモデリング、インポート、分析などをサポートします。 |
サポートされていないため、ユーザーはサードパーティのインターフェイスを統合する必要があります |
豊富な機能をサポート、2D および 3D 変換をサポート、ビジュアル データ モデリング、インポート、分析などをサポート。 |
| よく使用される組み込みのグラフ アルゴリズム |
豊富な基本グラフアルゴリズムを提供するインストールアルゴリズムパッケージを提供 |
サポートしません |
インストール アルゴリズム パッケージを提供し、独立したアルゴリズム パッケージの形式でユーザーに提供できる豊富なアルゴリズム ライブラリを備えています。 |
| 基本機能 (属性グラフの追加、削除、確認および変更、プランのメンテナンス、メタデータ、トランザクション、キャッシュ、クエリの最適化、グラフの増分更新など) |
サポート |
サポート |
サポート |
| ACIDトランザクション |
サポート |
バックエンド ストレージに応じて、部分的にサポートされます。 |
サポート |
| スキーマ制約 |
商用バージョンのサポート、スキーマフリーもサポート |
サポートされており、スキーマフリーもサポートされています |
サポートされており、スキーマフリーもサポートされています |
| グラフストレージタイプ |
ローカル ストレージのサポート、分散ストレージのサポート、クラウド管理ストレージのサポート |
ローカルストレージをフライングし、分散ストレージをサポート |
|
| グラフパーティション |
サポート |
サポート |
サポート |
| 高可用性 HA |
ビジネス版のサポート |
サポートは提供されません |
サポート |
上記のことからわかるように、NoSQL データベースが普及した理由は、ほとんどのデータ型や大規模なデータ収集などの課題を解決できるためですが、それらの違いは何ですか (単純にキーと値について話します)ペアとドキュメント）比較についてはどうですか？
文書の保存は階層構造であり、データをツリー構造として保存することは容易ですが、そのため上から下への従属関係しか表現できず、グラフデータベースにおいてツリー形状はその一つにすぎません。パフォーマンスがより豊かになります。また、ツリーストレージ構造では冗長なデータが複数埋め込まれるため、データの更新が困難になり、データの整合性が確保できなくなります。
キーと値のデータベースは、キーと値のペアの形式で編成、インデックス付け、保存されるため、データの関係が少量のアプリケーションに適しています。データ量が少ない場合は、読み取り回数を効果的に減らすことができます。ディスクへの書き込みが行われ、パフォーマンスが高いのですが、逆に、データ量が大きくなると、明白なグラフの方がデータ間の複雑な関係をより適切に表現できます。
最後に、すべてのグラフ データベースが同じように作成されているわけではないことに注意することが重要です。一部のグラフ データベースはストレージ機能のみを備え、コンピューティング機能を備えていません。また、他のグラフ データベースは計算を実行できますが、データ移行に関しては非常に非効率的です。NoSQL または MapReduce アーキテクチャを使用して実装されたグラフ データベースもいくつかありますが、グラフ コンピューティングの特性が完全かつ深く最適化されておらず、最終的には分散が水平になるほど効率が低下します。一部のメーカーは、すべてのデータを盲目的にメモリに移動するため、メモリ使用量が突然増加し、OOM が頻繁に発生してダウンタイムが発生するというマイナスの問題も生じます。正しい実装パスは、「分散 + ストレージとコンピューティングの統合 + マルチレベル ストレージの最適化 + グラフ クエリの深さの最適化」です。グラフ データベースには、真に高性能な分散グラフを設計して実装する方法について、多くの知識ポイントと課題が含まれています。データベースについては、「同時実行性の高いグラフ データベース システムを実装するにはどうすればよいですか?」を参照してください。3. ［文／ネザ・エマ］