快速了解什麼是知識圖譜, 如何以Neo4j圖形資料庫實作知識圖譜(knowledge graph)

Understand What is Knowledge Graph and how to implement it by Neo4j

什麼是知識圖譜

簡單的說就是透過給定的關係, 把不同種類的資料給連結在一起而得出的關係網路, 最後我們可以藉由查詢關係的方式來獲取更深一層的答案

目前已知的知識圖譜有Freebase, DBpedia, 以及Bio2RDF(如果有興趣的話可以去Google一下, 這邊就暫不作介紹)

那我們要如何實現知識圖譜?

要實現知識圖譜並不難, 首先要定義資料的關係, 再來就是要有個圖形資料庫來儲存資料以及關係

在接下來的篇幅裡會介紹如何使用Neo4j圖形資料庫來實作知識圖譜

為什麼要用知識圖譜與圖形資料庫

對於小型且關係不怎麼複雜的資料來說, 其時RDB就很夠用了, 但是當資料越長越大, 而且關係越來越複雜時, RDB就很難去處理這種情況

而圖形資料庫就是為了解決這問題存在的, 省去了用RDB時需要的反覆JOIN

但圖形資料庫也不是萬能的, 比如說, 他不適合大量的及時儲存, 他只適合讀取

一般而言, 資料庫可以大約分成三個特性CAP來討論
因為物理限制, 所以通常資料庫只能滿足其中兩項, 而另一項就可能被犧牲掉

CAP

CAP = Consistency + Availability + Partition tolerance 一致性(Consistency) 拿資料的時候可以保證資料一致, 無論用戶端怎麼讀取，都要能夠正確讀取最新的資料 可用性(Availability ) 快速回應能力 分割容忍(Partition tolerance) 這個能力關係到資料庫好不好以及容不容易擴展

圖形資料庫Neo4j 基本概念

資料庫的結構

每筆資料在知識圖譜裡都表示成一個節點Node , 每個節點裡面可以自帶一些屬性Property(比如說年齡, 性別, 工作), 而我們也可以在節點上黏上數個標籤Label來表示資料的類別, 當我們在查詢資料時就可以用Label來過濾資料而更精準地獲得答案, 除此之外節點與節點之間可以建立有向關係, 關係中也可以自帶屬性

如人:安海瑟威 ----(演過 { 收入: $1M } )---> 電影: 黑暗騎士

安海瑟威演出過黑暗騎士這部電影, 這個演出的關係中安海瑟威的片酬是$1M

簡單的說就是,

我們可以建立節點並給予標籤, 並且在節點間建立關係, 而每個節點又可以建立屬性來表達更詳細的資料特性

基本語法 建立資料 CREATE

這個範例就是建立四筆資料節點, 兩筆節點的標籤是Product, 一筆節點的標籤是Category, 而另一筆則是Supplier

查詢資料 MATCH RETURN MATCH 就有點像SQL中的FROM語法, 決定要從資料庫的哪裡去撈資料 RETURN 就像SELECT語法可以決定要撈出那些屬性比如: 若要把Product這個標籤底下的所有節點的name給撈出來, 查詢語法可以這樣寫

MATCH (x:Product)
RETURN x.name

建立關係

在Product跟Category之間建立一個PartOf的關係

建立Supplier與Product的關係也是如法炮製

MATCH (x:Product)
MATCH (y:Supplier)
CREATE (y)-[:]

最後下MATCH RETURN語法把結果印出來就是長這樣

當然實務上也可以透過更簡短的指令把剛剛的節點以及關係建好

CREATE (s:Supplier{name:'LG'})-[:Supply]->(x:Product{name:'Mobile'})-[:PartOf]->(y:Category{name:'3C'})

CREATE (s)-[:Supply]->(x2:Product{name:'TV'})-[:PartOf]->(y)

RETURN x,x2,y,s

WHERE 這個語法很直覺就是在WHERE指定一些條件式來過濾資料

總結

雖然圖形資料庫以更簡單且直覺的方式來儲存和表示資料, 但也有幾個缺點 1. 無法並行運算 2. 無法有效率的顯示即時資料結構 3. 應付大量更新會很吃力所以在採用圖形資料庫之前必須好好的評估一下對於專案的利弊, 而不是盲目的導入這個技術

黑皮考町

搜尋此網誌