這篇文章將為大家詳細(xì)講解有關(guān)怎么實(shí)現(xiàn)分布式圖數(shù)據(jù)庫(kù)Nebula Graph 的Index實(shí)踐，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

為昂昂溪等地區(qū)用戶提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及昂昂溪網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為網(wǎng)站設(shè)計(jì)制作、成都做網(wǎng)站、昂昂溪網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

導(dǎo)讀

索引是數(shù)據(jù)庫(kù)系統(tǒng)中不可或缺的一個(gè)功能，數(shù)據(jù)庫(kù)索引好比是書的目錄，能加快數(shù)據(jù)庫(kù)的查詢速度，其實(shí)質(zhì)是數(shù)據(jù)庫(kù)管理系統(tǒng)中一個(gè)排序的數(shù)據(jù)結(jié)構(gòu)。不同的數(shù)據(jù)庫(kù)系統(tǒng)有不同的排序結(jié)構(gòu)，目前常見的索引實(shí)現(xiàn)類型如 B-Tree index、B+-Tree index、B*-Tree index、Hash index、Bitmap index、Inverted index 等等，各種索引類型都有各自的排序算法。

雖然索引可以帶來(lái)更高的查詢性能，但是也存在一些缺點(diǎn)，例如：

• 創(chuàng)建索引和維護(hù)索引要耗費(fèi)額外的時(shí)間,往往是隨著數(shù)據(jù)量的增加而維護(hù)成本增大

• 索引需要占用物理空間

• 在對(duì)數(shù)據(jù)進(jìn)行增刪改的操作時(shí)需要耗費(fèi)更多的時(shí)間,因?yàn)樗饕惨M(jìn)行同步的維護(hù)

Nebula Graph 作為一個(gè)高性能的分布式圖數(shù)據(jù)庫(kù)，對(duì)于屬性值的高性能查詢，同樣也實(shí)現(xiàn)了索引功能。本文將對(duì) Nebula Graph的索引功能做一個(gè)詳細(xì)介紹。

圖數(shù)據(jù)庫(kù) Nebula Graph 術(shù)語(yǔ)

開始之前，這里羅列一些可能會(huì)使用到的圖數(shù)據(jù)庫(kù)和 Nebula Graph 專有術(shù)語(yǔ)：

• Tag：點(diǎn)的屬性結(jié)構(gòu)，一個(gè) Vertex 可以附加多種 tag，以 TagID 標(biāo)識(shí)。（如果類比 SQL，可以理解為一張點(diǎn)表）

• Edge：類似于 Tag，EdgeType 是邊上的屬性結(jié)構(gòu)，以 EdgeType 標(biāo)識(shí)。（如果類比 SQL，可以理解為一張邊表）

• Property：tag / edge 上的屬性值，其數(shù)據(jù)類型由 tag / edge 的結(jié)構(gòu)確定。

• Partition：Nebula Graph 的最小邏輯存儲(chǔ)單元，一個(gè) StorageEngine 可包含多個(gè) Partition。Partition 分為 leader 和 follower 的角色，Raftex 保證了 leader 和 follower 之間的數(shù)據(jù)一致性。

• Graph space：每個(gè) Graph Space 是一個(gè)獨(dú)立的業(yè)務(wù) Graph 單元，每個(gè) Graph Space 有其獨(dú)立的 tag 和 edge 集合。一個(gè) Nebula Graph 集群中可包含多個(gè) Graph Space。

• Index：本文中出現(xiàn)的 Index 指 nebula graph 中點(diǎn)和邊上的屬性索引。其數(shù)據(jù)類型依賴于 tag / edge。

• TagIndex：基于 tag 創(chuàng)建的索引，一個(gè) tag 可以創(chuàng)建多個(gè)索引。目前（2020.3）暫不支持跨 tag 的復(fù)合索引，因此一個(gè)索引只可以基于一個(gè) tag。

• EdgeIndex：基于 Edge 創(chuàng)建的索引。同樣，一個(gè) Edge 可以創(chuàng)建多個(gè)索引，但一個(gè)索引只可以基于一個(gè) edge。

• Scan Policy：Index 的掃描策略，往往一條查詢語(yǔ)句可以有多種索引的掃描方式，但具體使用哪種掃描方式需要 Scan Policy 來(lái)決定。

• Optimizer：對(duì)查詢條件進(jìn)行優(yōu)化，例如對(duì) where 子句的表達(dá)式樹進(jìn)行子表達(dá)式節(jié)點(diǎn)的排序、分裂、合并等。其目的是獲取更高的查詢效率。

索引需求分析

Nebula Graph 是一個(gè)圖數(shù)據(jù)庫(kù)系統(tǒng)，查詢場(chǎng)景一般是由一個(gè)點(diǎn)出發(fā)，找出指定邊類型的相關(guān)點(diǎn)的集合，以此類推進(jìn)行（廣度優(yōu)先遍歷）N 度查詢。另一種查詢場(chǎng)景是給定一個(gè)屬性值，找出符合這個(gè)屬性值的所有的點(diǎn)或邊。在后面這種場(chǎng)景中，需要對(duì)屬性值進(jìn)行高性能的掃描，查出與此屬性值對(duì)應(yīng)的邊或點(diǎn)，以及邊或點(diǎn)上的其它屬性。為了提高屬性值的查詢效率，在這里引入了索引的功能。對(duì)邊或點(diǎn)的屬性值進(jìn)行排序，以便快速的定位到某個(gè)屬性上。以此避免了全表掃描。

可以看到對(duì)圖數(shù)據(jù)庫(kù) Nebula Graph 的索引要求：

• 支持 tag 和 edge 的屬性索引

• 支持索引的掃描策略的分析和生成

• 支持索引的管理，如：新建索引、重建索引、刪除索引、list | show 索引等。

系統(tǒng)架構(gòu)概覽

圖數(shù)據(jù)庫(kù) Nebula Graph 存儲(chǔ)架構(gòu)

從架構(gòu)圖可以看到，每個(gè)Storage Server 中可以包含多個(gè) Storage Engine, 每個(gè) Storage Engine中可以包含多個(gè)Partition, 不同的Partition之間通過(guò) Raft 協(xié)議進(jìn)行一致性同步。每個(gè) Partition 中既包含了 data，也包含了 index，同一個(gè)點(diǎn)或邊的 data 和 index 將被存儲(chǔ)到同一個(gè) Partition 中。

業(yè)務(wù)具體分析

數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)

為了更好的描述索引的存儲(chǔ)結(jié)構(gòu)，這里將圖數(shù)據(jù)庫(kù) Nebula Graph 原始數(shù)據(jù)的存儲(chǔ)結(jié)構(gòu)一起拿出來(lái)分析下。

點(diǎn)的存儲(chǔ)結(jié)構(gòu)

點(diǎn)的 Data 結(jié)構(gòu)

點(diǎn)的 Index 結(jié)構(gòu)

Vertex 的索引結(jié)構(gòu)如上表所示，下面來(lái)詳細(xì)地講述下字段：

PartitionId：一個(gè)點(diǎn)的數(shù)據(jù)和索引在邏輯上是存放到同一個(gè)分區(qū)中的。之所以這么做的原因主要有兩點(diǎn)：

1. 當(dāng)掃描索引時(shí)，根據(jù)索引的 key 能快速地獲取到同一個(gè)分區(qū)中的點(diǎn) data，這樣就可以方便地獲取這個(gè)點(diǎn)的任何一種屬性值，即使這個(gè)屬性列不屬于本索引。

2. 目前 edge 的存儲(chǔ)是由起點(diǎn)的 ID Hash 分布，換句話說(shuō)，一個(gè)點(diǎn)的出邊存儲(chǔ)在哪是由該點(diǎn)的 VertexId 決定的，這個(gè)點(diǎn)和它的出邊如果被存儲(chǔ)到同一個(gè) partition 中，點(diǎn)的索引掃描能快速地定位該點(diǎn)的出邊。

IndexId：index 的識(shí)別碼，通過(guò) indexId 可獲取指定 index 的元數(shù)據(jù)信息，例如：index 所關(guān)聯(lián)的 TagId，index 所在列的信息。

Index binary：index 的核心存儲(chǔ)結(jié)構(gòu)，是所有 index 相關(guān)列屬性值的字節(jié)編碼，詳細(xì)結(jié)構(gòu)將在本文的 #Index binary# 章節(jié)中講解。

VertexId：點(diǎn)的識(shí)別碼，在實(shí)際的 data 中，一個(gè)點(diǎn)可能會(huì)有不同 version 的多行數(shù)據(jù)。但是在 index 中，index 沒(méi)有 Version 的概念，index 始終與最新 Version 的 Tag 所對(duì)應(yīng)。

上面講完字段，我們來(lái)簡(jiǎn)單地實(shí)踐分析一波：

假設(shè) PartitionId 為 100，TagId 有 tag_1 和 tag_2，其中 tag_1 包含三列 ：colt1_1、col_t1_2、col_t1_3，_tag_2 包含兩列：col_t2_1、col_t2_2。

現(xiàn)在我們來(lái)創(chuàng)建索引：

• i1 = tag_1 (col_t1_1, col_t1_2) ，假設(shè) i1 的 ID 為 1；

• i2 = tag_2(col_t2_1, col_t2_2),  假設(shè) i2 的 ID 為 2；

可以看到雖然 tag_1 中有 col_t1_3 這列，但是建立索引的時(shí)候并沒(méi)有使用到 col_t1_3，因?yàn)樵趫D數(shù)據(jù)庫(kù) Nebula Graph 中索引可以基于 Tag 的一列或多列進(jìn)行創(chuàng)建。

插入點(diǎn)

// VertexId = hash("v_t1_1")，假如為 50 
INSERT VERTEX tag_1(col_t1_1, col_t1_2, col_t1_3), tag_2(col_t2_1, col_t2_2) \
   VALUES hash("v_t1_1"):("v_t1_1", "v_t1_2", "v_t1_3", "v_t2_1", "v_t2_2");

從上可以看到 VertexId 可由 ID 標(biāo)識(shí)對(duì)應(yīng)的數(shù)值經(jīng)過(guò) Hash 得到，如果標(biāo)識(shí)對(duì)應(yīng)的數(shù)值本身已經(jīng)為 int64，則無(wú)需進(jìn)行 Hash 或者其他轉(zhuǎn)化數(shù)值為 int64 的運(yùn)算。而此時(shí)數(shù)據(jù)存儲(chǔ)如下：

此時(shí)點(diǎn)的 Data 結(jié)構(gòu)

此時(shí)點(diǎn)的 Index 結(jié)構(gòu)

說(shuō)明：index 中 row 和 key 是一個(gè)概念，為索引的唯一標(biāo)識(shí)；

邊的存儲(chǔ)結(jié)構(gòu)

邊的索引結(jié)構(gòu)和點(diǎn)索引結(jié)構(gòu)原理類似，這里不再贅述。但有一點(diǎn)需要說(shuō)明，為了使索引 key 的唯一性成立，索引的 key 的生成借助了不少 data 中的元素，例如 VertexId、SrcVertexId、Rank 等，這也是為什么點(diǎn)索引中并沒(méi)有 TagId 字段（邊索引中也沒(méi)有 EdgeType 字段），這是因?yàn)?strong> IndexId 本身帶有 VertexId 等信息可直接區(qū)分具體的 tagId 或 EdgeType。

邊的 Data 結(jié)構(gòu)

邊的 Index 結(jié)構(gòu)

Index binary 介紹

Index binary 是 index 的核心字段，在 index binary 中區(qū)分定長(zhǎng)字段和不定長(zhǎng)字段，int、double、bool 為定長(zhǎng)字段，string 則為不定長(zhǎng)字段。由于 index binary 是將所有 index column 的屬性值編碼連接存儲(chǔ)，為了精確地定位不定長(zhǎng)字段，Nebula Graph 在 index binary 末尾用 int32 記錄了不定長(zhǎng)字段的長(zhǎng)度。

舉個(gè)例子：

我們現(xiàn)在有一個(gè) index binary 為 index1，是由 int 類型的索引列1 c1、string 類型的索引列 c2，string 類型的索引列 c3 組成：

index1 (c1:int, c2:string, c3:string)

假如索引列 c1、c2、c3 某一行對(duì)應(yīng)的 property 值分別為：23、”abc”、”here”，則在 index1 中這些索引列將被存儲(chǔ)為如下（在示例中為了便于理解，我們直接用原值，實(shí)際存儲(chǔ)中是原值會(huì)經(jīng)過(guò)編碼再存儲(chǔ)）：

• length = sizeof(“abc”) = 3

• length = sizeof(“here”) = 4

所以 index1 該 row 對(duì)應(yīng)的 key 則為 23abchere34；

回到我們 Index binary 章節(jié)開篇說(shuō)的 index binary 格式中存在 Variable-length field lenght 字段，那么這個(gè)字段的的具體作用是什么呢？我們來(lái)簡(jiǎn)單地舉個(gè)例：

現(xiàn)在我們又有了一個(gè) index binary，我們給它取名為 index2，它由 string 類型的索引列1 c1、string 類型的索引列 c2，string 類型的索引列 c3 組成：

index2 (c1:string, c2:string, c3:string)

假設(shè)我們現(xiàn)在 c1、c2、c3 分別有兩組如下的數(shù)值：

• row1 : (“ab”, “ab”, “ab”)

• row2: (“aba”, “ba”, “b”)

可以看到這兩行的 prefix（上圖紅色部分）是相同，都是 “ababab”，這時(shí)候怎么區(qū)分這兩個(gè) row 的 index binary 的 key 呢？別擔(dān)心，我們有 Variable-length field lenght 。

若遇到 where c1 == “ab” 這樣的條件查詢語(yǔ)句，在 Variable-length field length 中可直接根據(jù)順序讀取出 c1 的長(zhǎng)度，再根據(jù)這個(gè)長(zhǎng)度取出 row1 和 row2 中 c1 的值，分別是 “ab” 和 “aba” ，這樣我們就精準(zhǔn)地判斷出只有 row1 中的 “ab” 是符合查詢條件的。

索引的處理邏輯

Index write

當(dāng) Tag / Edge中的一列或多列創(chuàng)建了索引后，一旦涉及到 Tag / Edge 相關(guān)的寫操作時(shí)，對(duì)應(yīng)的索引必須連同數(shù)據(jù)一起被修改。下面將對(duì)索引的write操作在storage層的處理邏輯進(jìn)行簡(jiǎn)單介紹：

INSERT——插入數(shù)據(jù)

當(dāng)用戶產(chǎn)生插入點(diǎn)/邊操作時(shí)，insertProcessor 首先會(huì)判斷所插入的數(shù)據(jù)是否有存在索引的 Tag 屬性 / Edge 屬性。如果沒(méi)有關(guān)聯(lián)的屬性列索引，則按常規(guī)方式生成新 Version，并將數(shù)據(jù) put 到 Storage Engine；如果有關(guān)聯(lián)的屬性列索引，則通過(guò)原子操作寫入 Data 和 Index，并判斷當(dāng)前的 Vertex / Edge 是否有舊的屬性值，如果有，則一并在原子操作中刪除舊屬性值。

DELETE——?jiǎng)h除數(shù)據(jù)

當(dāng)用戶發(fā)生 Drop Vertex / Edge 操作時(shí)，deleteProcessor 會(huì)將 Data 和 Index（如果存在）一并刪除，在刪除的過(guò)程中同樣需要使用原子操作。

UPDATE——更新數(shù)據(jù)

Vertex / Edge 的更新操作對(duì)于 Index 來(lái)說(shuō)，則是 drop 和 insert 的操作：刪除舊的索引，插入新的索引，為了保證數(shù)據(jù)的一致性，同樣需要在原子操作中進(jìn)行。但是對(duì)應(yīng)普通的 Data 來(lái)說(shuō)，僅僅是 insert 操作，使用最新 Version 的 Data 覆蓋舊 Version 的 data 即可。

Index scan

在圖數(shù)據(jù)庫(kù) Nebula Graph 中是用 LOOKUP 語(yǔ)句來(lái)處理 index scan 操作的，LOOKUP 語(yǔ)句可通過(guò)屬性值作為判斷條件，查出所有符合條件的點(diǎn)/邊，同樣 LOOKUP 語(yǔ)句支持 WHERE 和 YIELD 子句。

LOOKUP 使用技巧

正如根據(jù)本文#數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)#章節(jié)所描述那樣，index 中的索引列是按照創(chuàng)建 index 時(shí)的列順序決定。

舉個(gè)例子，我們現(xiàn)在有 tag (col1, col2)，根據(jù)這個(gè) tag 我們可以創(chuàng)建不同的索引，例如：

• index1 on tag(col1)

• index2 on tag(col2)

• index3 on tag(col1, col2)

• index4 on tag(col2, col1)

我們可以對(duì) clo1、col2 建立多個(gè)索引，但在 scan index 時(shí)，上述四個(gè) index 返回結(jié)果存在差異，甚至是完全不同，在實(shí)際業(yè)務(wù)中具體使用哪個(gè) index，及 index 的最優(yōu)執(zhí)行策略，則是通過(guò)索引優(yōu)化器決定。

下面我們?cè)賮?lái)根據(jù)剛才 4 個(gè) index 的例子深入分析一波：

lookup on tag where tag.col1 ==1  # 最優(yōu)的 index 是 index1
lookup on tag where tag.col2 == 2 # 最優(yōu)的 index 是index2
lookup on tag where tag.col1 > 1 and tag.col2 == 1 
# index3 和 index4 都是有效的 index，而 index1 和 index2 則無(wú)效

在上述第三個(gè)例子中，index3 和 index4 都是有效 index，但最終必須要從兩者中選出來(lái)一個(gè)作為 index，根據(jù)優(yōu)化規(guī)則，因?yàn)?tag.col2 == 1 是一個(gè)等價(jià)查詢，因此優(yōu)先使用 tag.col2 會(huì)更高效，所以優(yōu)化器應(yīng)該選出 index4 為最優(yōu) index。

實(shí)操一下圖數(shù)據(jù)庫(kù) Nebula Graph 索引

在這部分我們就不具體講解某個(gè)語(yǔ)句的用途是什么了，如果你對(duì)語(yǔ)句不清楚的話可以去圖數(shù)據(jù)庫(kù) Nebula Graph 的官方論壇進(jìn)行提問(wèn)： https://discuss.nebula-graph.io/

CREATE——索引的創(chuàng)建

(user@127.0.0.1:6999) [(none)]> CREATE SPACE my_space(partition_num=3, replica_factor=1);
Execution succeeded (Time spent: 15.566/16.602 ms)
Thu Feb 20 12:46:38 2020
(user@127.0.0.1:6999) [(none)]> USE my_space;
Execution succeeded (Time spent: 7.681/8.303 ms)
Thu Feb 20 12:46:51 2020
(user@127.0.0.1:6999) [my_space]> CREATE TAG lookup_tag_1(col1 string, col2 string, col3 string);
Execution succeeded (Time spent: 12.228/12.931 ms)
Thu Feb 20 12:47:05 2020
(user@127.0.0.1:6999) [my_space]> CREATE TAG INDEX t_index_1 ON lookup_tag_1(col1, col2, col3);
Execution succeeded (Time spent: 1.639/2.271 ms)
Thu Feb 20 12:47:22 2020

DROP——?jiǎng)h除索引

(user@127.0.0.1:6999) [my_space]> DROP TAG INDEX t_index_1;
Execution succeeded (Time spent: 4.147/5.192 ms)
Sat Feb 22 11:30:35 2020

REBUILD——重建索引

如果你是從較老版本的 Nebula Graph 升級(jí)上來(lái)，或者用 Spark Writer 批量寫入過(guò)程中（為了性能）沒(méi)有打開索引，那么這些數(shù)據(jù)還沒(méi)有建立過(guò)索引，這時(shí)可以使用 REBUILD INDEX 命令來(lái)重新全量建立一次索引。這個(gè)過(guò)程可能會(huì)耗時(shí)比較久，在 rebuild index 完成前，客戶端的讀寫速度都會(huì)變慢。

REBUILD {TAG | EDGE} INDEX <index_name> [OFFLINE]

LOOKUP——使用索引

需要說(shuō)明一下，使用 LOOKUP 語(yǔ)句前，請(qǐng)確保已經(jīng)建立過(guò)索引（CREATE INDEX 或 REBUILD INDEX）。

(user@127.0.0.1:6999) [my_space]> INSERT VERTEX lookup_tag_1(col1, col2, col3) VALUES 200:("col1_200", "col2_200", "col3_200"),  201:("col1_201", "col2_201", "col3_201"), 202:("col1_202", "col2_202", "col3_202");
Execution succeeded (Time spent: 18.185/19.267 ms)
Thu Feb 20 12:49:44 2020
(user@127.0.0.1:6999) [my_space]> LOOKUP ON lookup_tag_1 WHERE lookup_tag_1.col1 == "col1_200";
============
| VertexID |
============
| 200      |
------------
Got 1 rows (Time spent: 12.001/12.64 ms)
Thu Feb 20 12:49:54 2020
(user@127.0.0.1:6999) [my_space]> LOOKUP ON lookup_tag_1 WHERE lookup_tag_1.col1 == "col1_200" YIELD lookup_tag_1.col1, lookup_tag_1.col2, lookup_tag_1.col3;
========================================================================
| VertexID | lookup_tag_1.col1 | lookup_tag_1.col2 | lookup_tag_1.col3 |
========================================================================
| 200      | col1_200          | col2_200          | col3_200          |
------------------------------------------------------------------------
Got 1 rows (Time spent: 3.679/4.657 ms)
Thu Feb 20 12:50:36 2020

關(guān)于怎么實(shí)現(xiàn)分布式圖數(shù)據(jù)庫(kù)Nebula Graph 的Index實(shí)踐就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

文章名稱：怎么實(shí)現(xiàn)分布式圖數(shù)據(jù)庫(kù)NebulaGraph的Index實(shí)踐-創(chuàng)新互聯(lián)
網(wǎng)址分享：http://aaarwkj.com/article6/cojiog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)公司、ChatGPT、用戶體驗(yàn)、App開發(fā)、網(wǎng)站制作、關(guān)鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)