前言：

隨著社交、電商、金融、物聯(lián)網(wǎng)等行業(yè)的快速發(fā)展，現(xiàn)實組成了一張龐大的關(guān)系網(wǎng)，傳統(tǒng)數(shù)據(jù)庫很難處理關(guān)系運算，大數(shù)據(jù)行業(yè)需要處理的數(shù)據(jù)之間的關(guān)系隨著數(shù)據(jù)量呈幾何指數(shù)增長，亟需一種支持海量復雜數(shù)據(jù)關(guān)系運算的數(shù)據(jù)庫，圖數(shù)據(jù)庫應運而生。本文將探討圖數(shù)據(jù)庫在數(shù)據(jù)資產(chǎn)可視化中的應用。

目錄：

1．圖數(shù)據(jù)庫介紹

2．關(guān)系型數(shù)據(jù)庫和圖數(shù)據(jù)庫的區(qū)別

3．探索圖數(shù)據(jù)庫在數(shù)據(jù)資產(chǎn)可視化中的應用

1．圖數(shù)據(jù)庫介紹

這張圖是一個社交網(wǎng)絡場景，每個用戶可以發(fā)短信、發(fā)郵件，分享信息。這些都是最基本的增刪改查，也是大多數(shù)研發(fā)人員對數(shù)據(jù)庫做的常見操作。而在研發(fā)人員的日常工作中除了要把用戶的基本信息錄入數(shù)據(jù)庫外，還需找到與該用戶相關(guān)聯(lián)的信息，方便去對單個的用戶進行下一步的分析，比如說：我們發(fā)現(xiàn)張三的賬戶里有很多關(guān)于推理小說和音樂方面的內(nèi)容，那么我們可以據(jù)此推測出他可能是一名學生，從而推送他可能感興趣的內(nèi)容。

但是在數(shù)據(jù)分析過程中，會出現(xiàn)各種各樣的場景，比如說在一個典型的社交網(wǎng)絡中，常常會存在“誰認識誰，誰上過什么學校，誰常住什么地方，誰喜歡什么餐館”等查詢，這種查詢在數(shù)據(jù)分析過程中是很常見的，但是這種操作會因為數(shù)據(jù)庫的選擇不同而對性能產(chǎn)生巨大的差異。

傳統(tǒng)數(shù)據(jù)庫解決思路

傳統(tǒng)解決上述問題最簡單的方法就是建立一個關(guān)系模型，我們可以把每個員工的信息錄入表中，存在諸如 MySQL 之類的關(guān)系數(shù)據(jù)庫，圖片展示的是最基本的關(guān)系模型圖。

基于上述的關(guān)系模型，依據(jù)需求，就不可避免的涉及到很多庫表的join操作，實現(xiàn)的查詢語句可能也會很長，并且這種代碼可讀性很差，而且會有嚴重的性能問題。關(guān)于傳統(tǒng)關(guān)系數(shù)據(jù)庫的性能問題我們后續(xù)分析。

圖數(shù)據(jù)庫解決思路

在傳統(tǒng)數(shù)據(jù)庫雖然運用 JOIN 操作把不同的表鏈接了起來，從而隱式地表達了數(shù)據(jù)之間的關(guān)系，但是當我們要通過 A 管理 B，B 管理 A 的方式查詢結(jié)果時，表結(jié)構(gòu)并不能直接告訴我們結(jié)果。如果我們想在做查詢前就知道對應的查詢結(jié)果，我們必須先定義節(jié)點和關(guān)系。使用圖結(jié)構(gòu)建模，節(jié)點和關(guān)系先定義是圖數(shù)據(jù)庫和別的數(shù)據(jù)庫的核心區(qū)別。

打個比方，我們可以把經(jīng)理、員工表示成不同的節(jié)點，并用一條邊來代表他們之前存在的管理關(guān)系，或者把用戶和商品看作節(jié)點，用購買關(guān)系建模等等。而當我們需要新的節(jié)點和關(guān)系時，只需進行幾次更新就好，而不用去改變表的結(jié)構(gòu)或者去遷移數(shù)據(jù)。根據(jù)節(jié)點和關(guān)聯(lián)關(guān)系，傳統(tǒng)數(shù)據(jù)庫建�？梢赞D(zhuǎn)換為圖片所示建模：

在通過圖數(shù)據(jù)庫原生圖查詢語言（Cypher）進行建模和查詢后，近百行的sql代碼變成3，4行的代碼可以明顯的看出圖數(shù)據(jù)庫在數(shù)據(jù)表達上的優(yōu)勢：

MATCH （boss）－［：MANAGES＊0．．3］－＞（sub）， （sub）－［：MANAGES＊1．．3］－＞（userid） WHERE boss．name ＝ “zhangsan” RETURN sub．name AS list， count（userid） AS Total

什么是圖

圖的定義：A database that uses graph structures for semantic queries with nodes， edges and properties to represent and store data – independent of the way the data is stored internally． It’s really the model and the implemented algorithms that matter．

圖數(shù)據(jù)庫是基于圖模型的數(shù)據(jù)庫。相比較于關(guān)系型數(shù)據(jù)庫，圖數(shù)據(jù)庫是真正注重“關(guān)系”的數(shù)據(jù)庫。圖數(shù)據(jù)庫的主要職能是管理圖數(shù)據(jù)，因此需要支持高效的對頂點／邊的查詢與更新；為了方便用戶的使用，通常還需要增加對事務（transaction）的支持，從而保證并發(fā)操作下的正常運作。

圖廣泛存在于現(xiàn)實世界中，從社交網(wǎng)絡到金融關(guān)系，都會涉及大量的高度關(guān)聯(lián)數(shù)據(jù)。這些數(shù)據(jù)構(gòu)成了龐大的圖，圖數(shù)據(jù)庫就是呈現(xiàn)和查詢這些關(guān)聯(lián)的方式。這種聯(lián)系形成了一種互相關(guān)聯(lián)的數(shù)據(jù)，聯(lián)系才是數(shù)據(jù)的本質(zhì)所在。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫并不能很好地表現(xiàn)數(shù)據(jù)的聯(lián)系，而一些NoSQL（Not Only SQL，非關(guān)系型數(shù)據(jù)庫）數(shù)據(jù)庫又不能表現(xiàn)數(shù)據(jù)之間的聯(lián)系。同樣屬于NoSQL范疇的圖數(shù)據(jù)庫是以圖的結(jié)構(gòu)形式來存儲數(shù)據(jù)的，它所存儲的就是聯(lián)系的數(shù)據(jù)，是關(guān)聯(lián)數(shù)據(jù)本身。

然而關(guān)聯(lián)數(shù)據(jù)中的聯(lián)系本來就很復雜，若要在關(guān)系型數(shù)據(jù)庫中使用結(jié)構(gòu)化形式來表現(xiàn)這種聯(lián)系，則一般不能直接表示，處理起來既煩瑣又費事，并且隨著數(shù)據(jù)的不斷增長，其訪問性能將日趨下降。無數(shù)的開發(fā)人員和數(shù)據(jù)庫管理人員都或多或少地使用過關(guān)系型數(shù)據(jù)庫，在其應用的規(guī)�；�進展過程中，對于數(shù)據(jù)庫的性能優(yōu)化往往捉襟見肘、陷入窘境。圖數(shù)據(jù)庫沒有模式結(jié)構(gòu)的定義，也不需要這些定義，它使用非結(jié)構(gòu)化的方式來存儲關(guān)聯(lián)數(shù)據(jù)，所以能夠直接表現(xiàn)數(shù)據(jù)的關(guān)聯(lián)特性。

圖數(shù)據(jù)庫的發(fā)展趨勢

在眾多不同的數(shù)據(jù)模型里，關(guān)系數(shù)據(jù)模型自20世紀80年代就處于統(tǒng)治地位，而且出現(xiàn)了不少巨頭，如Oracle、MySQL，它們也被稱為：關(guān)系數(shù)據(jù)庫管理系統(tǒng)（RDBMS）。然而，隨著關(guān)系數(shù)據(jù)庫使用范圍的不斷擴大，也暴露出一些它始終無法解決問題，其中最主要的是數(shù)據(jù)建模中的一些缺陷和問題，以及在大數(shù)據(jù)量和多服務器之上進行水平伸縮的限制。同時，互聯(lián)網(wǎng)發(fā)展也產(chǎn)生了一些新的趨勢變化：用戶、系統(tǒng)和傳感器產(chǎn)生的數(shù)據(jù)量呈指數(shù)增長，數(shù)據(jù)量不斷增加，大數(shù)據(jù)的存儲和處理；新時代互聯(lián)網(wǎng)形勢下的問題急迫性，這一問題因互聯(lián)網(wǎng)＋、社交網(wǎng)絡，智能推薦等的大規(guī)模興起和繁榮而變得越加緊迫。而在應對這些趨勢時，關(guān)系數(shù)據(jù)庫產(chǎn)生了更多的不適應性，從而導致大量解決這些問題中某些特定方面的不同技術(shù)出現(xiàn)，它們可以與現(xiàn)有RDBMS相互配合或代替它們。過去的幾年間，出現(xiàn)了大量新型數(shù)據(jù)庫，它們被統(tǒng)稱為NoSQL數(shù)據(jù)庫。其中圖數(shù)據(jù)庫從最近十年的表現(xiàn)來看已經(jīng)成為關(guān)注度最高，也是發(fā)展趨勢最明顯的數(shù)據(jù)庫類型。