この記事は、 Cuntou Shuxia によるHuawei Cloud Community 「Huawei Cloud GES Persistence Graph Database の複合インデックスの紹介」から共有されたものです。
この記事ではインデックスの役割とその実装方法を中心に紹介しますので、インデックスの役割と使い方の理解に役立てていただければ幸いです。
1. 複合インデックスとは何ですか?
複合インデックスは、クエリを高速化するためにユーザーが手動で作成する追加データの一種です。詳細なパラメータについては仕様書を参照してください。
https://support.huaweicloud.com/api-ges/ges_03_0454.html
2. 複合インデックスでできることは何ですか?
複合インデックスには 2 つのタイプがあります。1 つはラベル インデックスで、ラベルのスキャンを高速化するために使用されます。2 つ目は属性インデックスで、属性のフィルタリングを高速化するために使用されます。
以下は、いくつかの一般的なインターフェイス (ステートメント) とインデックスの間の関係のリストです。
| APIインターフェース |
インデックス加速方式 |
|---|---|
| まとめ |
ラベルインデックスをスキャンし、各ラベルのポイントとエッジの数をカウントします。 |
| match (n:user) return count(*) |
ポイント ラベル インデックスをスキャンし、ラベルがユーザーであるポイントの数をカウントします。 |
| match ()-[r:label]-() return count® |
エッジラベルインデックスをスキャンし、指定されたラベルポイントの数をカウントします。 |
| 一致 (n:user) n を返す 制限 1 |
ポイント ラベル インデックスを使用して、ラベル ユーザーのポイントをすばやく検索します |
| match (n:user) where n.age > 10 return n 制限 1 |
ラベル インデックスのみがある場合は、ラベル インデックスをスキャンしてユーザー ポイントを見つけ、属性フィルタリングを実行します。年齢属性インデックスがある場合は、その属性インデックスを直接使用して対象地点を特定します。 |
| match (n:user) where n.age in [1, 10] は n を返します 制限 1 |
同上 |
3. インデックスがない場合のクエリ方法
まずインデックスを使用しないクエリ ロジックを理解すると、これに基づいてインデックスがクエリを高速化するために何を行うかを理解できます。クエリ ロジックは主に、データ構造、データ アクセス方法、クエリ シナリオの 2 つの側面に関連しています。
a) 元の点構造
永続バージョンのすべてのデータは、KV (キーと値のペア) の形式で分散 KV データベースに保存されます。インデックスが作成されない場合、データベースには元のエッジ KV のみが存在します。例としてポイント データ構造を取ります。
鍵： 
価値：
キーの先頭部分は kVType です。これは、さまざまな種類のデータを区別するためにすべてのデータに存在する固定プレフィックスです。Vid はグローバルに一意のポイント ID です。Labelid は、ラベルを識別する組み込みのエンコーディングです。値は属性のデータです。
b) データアクセス方法
すべてのグラフ データ クエリは、最終的には KV データベースへのアクセスに依存します。KV データにアクセスするには、一般的に 2 つの方法が使用されます。
- 正確なクエリ インターフェイス。完全なキー クエリ値を指定します。
- プレフィックス クエリ インターフェイスは、キーのプレフィックス部分のみを指定し、すべてのキーのプレフィックスに一致する KV データ ペアをクエリします。プレフィックス検索は比較的頻繁に使用されます。シナリオでは複数のプレフィックス検索が必要になる場合があります。プレフィックス クエリを実行するほど、より多くの結果が得られるため、このシナリオの応答速度は遅くなります。プレフィックス検索結果のサイズはプレフィックスの長さに直接関係しており、プレフィックスが長いか正確であるほど、プレフィックス検索結果の数は少なくなります。必要な計算が少なくなります。応答速度が速くなります。
c) クエリシナリオ:
対応する kv レイヤー インターフェイスでは、一般的なクエリ シナリオが必要になります。
| シーン |
KV インターフェースと通話時間 |
クエリ速度 |
対応するCypherステートメント |
|---|---|---|---|
| 指定したIDでフィルタリングする |
プレフィックスチェック※1 |
高速です。KVType と Vid が既知であるため、プレフィックスを詳しく説明できます。同時に、一般に ID にはあまり多くのラベルが含まれておらず、プレフィックス検索の結果もそれほど大きくありません。 |
match（n） where id(n)='0' return n |
| ラベルフィルターを指定する |
プレフィックスチェック
n + フィルター
メートル
|
遅いです。Vid が不明なため、最初に KVType のみでプレフィックスをスペルアウトし、次にプレフィックスですべてのポイントを見つけてから、ラベルを 1 つずつフィルタリングすることしかできません。ポイント データが大量にある場合は、複数のプレフィックス チェックがあり、バッチで取得されてフィルタリングされます。 |
一致（n:ラベル） n を返す |
| ラベル+属性フィルタリングを指定する |
プレフィックスチェック
n + フィルター
メートル
|
遅いです。クエリ プレフィックスは KvType です。すべての画像ポイントを走査し、最初にラベル フィルタリングを実行し、次に属性フィルタリングを実行します。 |
match (n:Label) where n.prop='xx' return n |
| 属性フィルターの指定 |
プレフィックスチェック
n + フィルター
メートル
|
非常に遅いです。クエリのプレフィックスは KvType で、すべてのマップ ポイントを走査し、すべてのマップ ポイントに対して属性フィルタリングを実行します。 |
match (n) where n.prop='xx' return n |
ID を指定するクエリを除いて、他のすべてのクエリが非常に遅いことがわかります。これらのクエリでは、結果を取得するためにマップ ポイント全体のスキャンとフィルタリングが必要です。これは、クエリから取得される結果の数とは関係ありません。大きなグラフの場合、このようなクエリは非常にコストがかかります。
4. 複合インデックスを高速化する方法
クエリが遅いシナリオは、ラベル クエリまたは属性クエリの 2 つだけです。インデックスがない場合、両方のクエリはフィルタリングのためのグローバル ポイント スキャンに基づいています。有効なデータの割合が低い場合 (たとえば、1w のグローバル ポイントと 1 つのターゲット ポイントのみ)、このスキャン方法のコスト効率は低くなります。
これら 2 つのシナリオでは、対応するインデックスを作成できます。インデックス自体もKVデータです。したがって、キーのレイアウトによってその機能が決まります。
1. ラベル フィルタリング シナリオの場合、インデックス キーの形式は次のとおりです。
各ポイントには、対応するラベル インデックス KV があります。
特定のラベルをフィルターする必要がある場合は、KVType+Label のプレフィックスを指定し、kv データベースのプレフィックス クエリ インターフェイスを使用して、条件を満たすすべてのポイントを直接フィルターで除外できます。
2. 属性フィルタリング シナリオの場合、インデックスのキー形式は次のとおりです。
属性インデックスは、より頻繁にフィルタリングされる個々の属性に対してのみ作成されます。したがって、属性インデックス kv は、この属性を含むポイントに対してのみ生成されます。Label インデックスと比較すると、プロパティ フィールドが 1 つだけ増えています。このフィールドには、Vid ポイントに対応する属性の値が入力されます。プロパティ フィールドにはすべてのポイント属性が含まれるわけではなく、フィルターされる属性の値のみが含まれることに注意してください。
属性クエリを実行する場合、ターゲット値はわかっているため (たとえば、n.prop=1 の場合、ターゲット値は 1)。KVTypr+Label+Property を直接記述し、プレフィックス クエリ インターフェイスを呼び出します。条件を満たすすべてのポイントを検索できます。
インデックスを使用して一致するインデックス KV を見つけた後、対応する VId を簡単に取得できます。次に、この Vid に基づいて、このポイントの属性、近傍、その他の情報をすばやくクエリできます。
5. インデックス作成に関するいくつかの提案
インデックス作成は無料ではなく、クエリを高速化できますが、書き込み操作のパフォーマンスが低下し、より多くのディスク領域を消費します。したがって、インデックスを作成する前に、インデックスが必要かどうかを検討する必要があります。これは、データの差別化、データサイズ、アクセス頻度の 3 つの側面から評価できます。
- データの識別: フィルタリング性の高い属性に対して属性インデックスを確立することをお勧めします。価値の分布がより分散され、確立に適しています。たとえば、ID 番号、携帯電話番号などです。ただし、性別属性については、設定することはお勧めしません。ラベル インデックスについては、ピクチャ内にラベルが 1 つしかない場合、ラベル インデックスを構築する必要はありませんが、ほとんどの場合、ラベル インデックスが必要です。
- データサイズ: これは主に属性インデックス用です。既にラベルインデックスが存在するという前提の下で、特定のラベルの下の点とエッジの数が非常に少ない場合は、すべてのラベルをスキャンしてもコストはかかりません。追加する必要はありません。属性インデックスを作成します。
- アクセス頻度: これはわかりやすいですが、where 句に頻繁に出現する属性のみがインデックスされます。
クリックしてフォローし、できるだけ早くHuawei Cloudの新しいテクノロジーについて学びましょう~
200元の罰金と100万元以上を没収 You Yuxi: 高品質の中国語文書の重要性 MuskのJDK 21用ハードコア移行サーバー Solon、仮想スレッドは信じられないほど素晴らしい！！！ TCP 輻輳制御によりインターネットが節約される OpenHarmony 用の Flutter が登場 Linux カーネルの LTS 期間が 6 年から 2 年に復元される Go 1.22 で for ループ変数エラーが修正される Svelte は「新しいホイール」を作成 - ルーン文字 Google が創立 25 周年を祝う