索引雖然能加速查詢，但是會降低寫操作的性能，以及耗費更多的磁碟空間。所以建立索引之前需要考慮是不是必要的。 ...
本文分享自華為雲社區 《華為雲GES持久化圖資料庫複合索引介紹》，作者：村頭樹下。
本文章主要介紹索引的作用，以及如何實現這種功能，希望可以幫助理解索引的作用以及如何使用索引
1. 什麼是複合索引
複合索引是用戶手動建立的用於加速查詢的一類額外數據。詳細參數可以參考規格文檔
https://support.huaweicloud.com/api-ges/ges_03_0454.html
2. 複合索引能做什麼
複合索引有兩類。一是label索引，用於加速label的掃描。二是屬性索引，用於加速屬性過濾。
這裡列舉了一些常用介面（語句）與索引的關係
|
api介面 |
索引加速方式 |
|---|---|
|
summary |
掃描label索引，統計各label點邊數目 |
|
match (n:user) return count(*) |
掃描點label索引，統計label為user的點數目 |
|
match ()-[r:label]-() return count® |
掃描邊label索引，統計指定label點數目 |
|
match (n:user) return n limit 1 |
通過點label索引快速尋找label為user的點 |
|
match (n:user) where n.age > 10 return n limit 1 |
僅有label索引時掃描label索引，尋找user的點，然後進行屬性過濾。當存在age屬性索引時直接使用屬性索引定位到目標點 |
|
match (n:user) where n.age in [1, 10] return n limit 1 |
同上 |
3. 無索引時如何查詢
首先瞭解無索引的情況下，查詢的邏輯，才可以理解索引在此基礎上做了什麼使得查詢能夠加速。查詢邏輯主要與兩個方面有關：數據結構，以及數據訪問方式，以及查詢場景。
a) 原始點結構
持久化版本所有數據都是以KV（鍵值對）的方式存儲在分散式KV資料庫中，在沒有建立索引的時候，資料庫中僅有原始點邊KV。以點數據結構為例：
Key: 
Value:
key的開始部分為kVType，這是所有數據都會存在的固定首碼，用以區分不同類型的數據。然後是Vid是全局唯一點id。Labelid是標識label的內置編碼。Value則是屬性的數據。
b) 數據訪問方式
所有的圖數據的查詢最終都是依托於KV資料庫的訪問。常用的訪問KV數據的方式有兩種：
- 精確查詢介面，指定完整的key查詢value
- 首碼查詢介面，僅指定key的首碼部分，查詢所有key的首碼匹配的KV數據對。首碼查相對來說會更加頻繁的使用。一個場景可能會需要多次首碼查，而首碼查的次數越多，結果越多，相應的此場景響應速度就越慢。首碼查結果大小直接與首碼的長度有關，首碼越長或者越精確，那麼首碼查的結果越少。需要的計算量也越少。相應速度就會越快。
c) 查詢場景：
常見查詢場景的對應的kv層介面調用：
|
場景 |
KV介面及調用次數 |
查詢速度 |
對應Cypher語句 |
|---|---|---|---|
|
指定id過濾 |
首碼查 * 1 |
快，由於KVType和Vid已知，可以拼出首碼，同時一個id一般不會有太多label，首碼查的結果不會特別多。 |
match（n） where id(n)=‘0’ return n |
|
指定label過濾 |
首碼查 n + 過濾 m
|
慢， 由於不知道Vid，所以只能先拼出只有KVType的首碼，然後首碼查出所有點，再逐個過濾Label,點數據較多時，會有多次首碼查，分批獲取再過濾。 |
match（n:Label） return n |
|
指定label+屬性過濾 |
首碼查 n + 過濾 m
|
慢， 查詢首碼為KvType,遍歷全圖點，先進行Label過濾，再進行屬性過濾 |
match (n:Label) where n.prop=‘xx’ return n |
|
指定屬性過濾 |
首碼查 n + 過濾 m
|
非常慢， 查詢首碼為KvType,遍歷全圖點，全部進行屬性過濾 |
match (n) where n.prop=‘xx’ return n |
可見，除了指定id的查詢，其他所有查詢均非常慢。這些查詢都需要進行全圖點掃描加過濾的方式來獲取結果。這與查詢出來的結果數目無關。對於較大的圖來說，這樣的查詢代價是十分巨大的。
4. 複合索引如何加速
查詢慢的場景無外乎兩種場景，label查詢或者屬性查詢。在沒有索引的情況下，這兩種查詢都是建立在全局點掃描的基礎上，進行過濾。當有效數據占比越低（例如全局點1w,目標點僅有1個），這種掃描方式就越顯得不划算。
對於這兩種場景，我們可以建立對應的索引。索引本身也是KV數據。所以其key的佈局就決定了其功能。
1.對於label過濾場景，索引的key的格式為：
對於每一個點，都會有一條對應的Label索引KV。
當需要過濾特定Label時，可以拼出KVType+Label的首碼，利用kv數據底座的首碼查介面，就能直接將所有符合條件的點過濾出來。
2. 對於屬性過濾的場景，索引的key格式為：
屬性索引只針對個別過濾較為頻繁的屬性而建立。所以也只會對包含此屬性的點才會生成屬性索引kv。相比於Label索引這裡只是多了一個property欄位。此欄位填的是Vid對應點的屬性的值。需要註意的是，property欄位並不包含全部的點屬性，僅僅是待過濾屬性的值。
當進行屬性查詢時，由於知道目標值（例如where n.prop=1,目標值就是1）。直接拼出KVTypr+Label+Property，調用首碼查詢介面。即可查出所有符合條件的點。
當利用索引查出匹配的索引KV之後，就可以很方便的拿到對應的VId。然後根據此Vid，就能快速查詢到這個點的屬性，或者鄰居等信息。
5. 索引建立的若幹建議
索引並不是沒有代價的，雖然它能加速查詢，但是會降低寫操作的性能，以及耗費更多的磁碟空間。所以建立索引之前需要考慮是不是必要的。這可以從數據區分度，數據大小，以及訪問頻率三個方面來評估。
- 數據區分度：對於屬性索引建議在過濾性好的屬性上建立。值分佈較為分散，比較適合建立。例如身份證號，手機號。但是對於性別這種屬性，就不建議為此建立。對於label索引，如果圖裡面只有一個label，那麼建label索引其實也是沒有什麼必要的，但是大部分情況，label索引都是必要的。
- 數據大小：這主要是針對屬性索引來說的，在已經有Label索引的前提下，如果某個label下的點邊數目很少，即使掃描所有label代價也不高，這時候沒有必要再為其建立屬性索引。
- 訪問頻率：這一點很好理解，只對頻繁在where子句中出現的屬性建立索引。
