前言：

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

目錄：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖廣泛存在于現(xiàn)實(shí)世界中，從社交網(wǎng)絡(luò)到金融關(guān)系，都會(huì)涉及大量的高度關(guān)聯(lián)數(shù)據(jù)。這些數(shù)據(jù)構(gòu)成了龐大的圖，圖數(shù)據(jù)庫(kù)就是呈現(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ù)庫(kù)并不能很好地表現(xiàn)數(shù)據(jù)的聯(lián)系，而一些NoSQL（Not Only SQL，非關(guān)系型數(shù)據(jù)庫(kù)）數(shù)據(jù)庫(kù)又不能表現(xiàn)數(shù)據(jù)之間的聯(lián)系。同樣屬于NoSQL范疇的圖數(shù)據(jù)庫(kù)是以圖的結(jié)構(gòu)形式來(lái)存儲(chǔ)數(shù)據(jù)的，它所存儲(chǔ)的就是聯(lián)系的數(shù)據(jù)，是關(guān)聯(lián)數(shù)據(jù)本身。

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

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

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