前言：
隨著社交、電商、金融、物聯(lián)網(wǎng)等行業(yè)的快速發(fā)展，現(xiàn)實組成了一張龐大的關系網(wǎng)，傳統(tǒng)數(shù)據(jù)庫很難處理關系運算，大數(shù)據(jù)行業(yè)需要處理的數(shù)據(jù)之間的關系隨著數(shù)據(jù)量呈幾何指數(shù)增長，亟需一種支持海量復雜數(shù)據(jù)關系運算的數(shù)據(jù)庫，圖數(shù)據(jù)庫應運而生。本文將探討圖數(shù)據(jù)庫在數(shù)據(jù)資產(chǎn)可視化中的應用。
目錄：
1．圖數(shù)據(jù)庫介紹
2．關系型數(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ù)庫外，還需找到與該用戶相關聯(lián)的信息，方便去對單個的用戶進行下一步的分析，比如說：我們發(fā)現(xiàn)張三的賬戶里有很多關于推理小說和音樂方面的內容，那么我們可以據(jù)此推測出他可能是一名學生，從而推送他可能感興趣的內容。
但是在數(shù)據(jù)分析過程中，會出現(xiàn)各種各樣的場景，比如說在一個典型的社交網(wǎng)絡中，常常會存在“誰認識誰，誰上過什么學校，誰常住什么地方，誰喜歡什么餐館”等查詢，這種查詢在數(shù)據(jù)分析過程中是很常見的，但是這種操作會因為數(shù)據(jù)庫的選擇不同而對性能產(chǎn)生巨大的差異。
傳統(tǒng)數(shù)據(jù)庫解決思路
傳統(tǒng)解決上述問題最簡單的方法就是建立一個關系模型，我們可以把每個員工的信息錄入表中，存在諸如 MySQL 之類的關系數(shù)據(jù)庫，圖片展示的是最基本的關系模型圖。
基于上述的關系模型，依據(jù)需求，就不可避免的涉及到很多庫表的join操作，實現(xiàn)的查詢語句可能也會很長，并且這種代碼可讀性很差，而且會有嚴重的性能問題。關于傳統(tǒng)關系數(shù)據(jù)庫的性能問題我們后續(xù)分析。
圖數(shù)據(jù)庫解決思路
在傳統(tǒng)數(shù)據(jù)庫雖然運用 JOIN 操作把不同的表鏈接了起來，從而隱式地表達了數(shù)據(jù)之間的關系，但是當我們要通過 A 管理 B，B 管理 A 的方式查詢結果時，表結構并不能直接告訴我們結果。如果我們想在做查詢前就知道對應的查詢結果，我們必須先定義節(jié)點和關系。使用圖結構建模，節(jié)點和關系先定義是圖數(shù)據(jù)庫和別的數(shù)據(jù)庫的核心區(qū)別。
打個比方，我們可以把經(jīng)理、員工表示成不同的節(jié)點，并用一條邊來代表他們之前存在的管理關系，或者把用戶和商品看作節(jié)點，用購買關系建模等等。而當我們需要新的節(jié)點和關系時，只需進行幾次更新就好，而不用去改變表的結構或者去遷移數(shù)據(jù)。根據(jù)節(jié)點和關聯(lián)關系，傳統(tǒng)數(shù)據(jù)庫建模可以轉換為圖片所示建模：
在通過圖數(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ù)庫。相比較于關系型數(shù)據(jù)庫，圖數(shù)據(jù)庫是真正注重“關系”的數(shù)據(jù)庫。圖數(shù)據(jù)庫的主要職能是管理圖數(shù)據(jù)，因此需要支持高效的對頂點／邊的查詢與更新；為了方便用戶的使用，通常還需要增加對事務（transaction）的支持，從而保證并發(fā)操作下的正常運作。
圖廣泛存在于現(xiàn)實世界中，從社交網(wǎng)絡到金融關系，都會涉及大量的高度關聯(lián)數(shù)據(jù)。這些數(shù)據(jù)構成了龐大的圖，圖數(shù)據(jù)庫就是呈現(xiàn)和查詢這些關聯(lián)的方式。這種聯(lián)系形成了一種互相關聯(lián)的數(shù)據(jù)，聯(lián)系才是數(shù)據(jù)的本質所在。傳統(tǒng)的關系型數(shù)據(jù)庫并不能很好地表現(xiàn)數(shù)據(jù)的聯(lián)系，而一些NoSQL（Not Only SQL，非關系型數(shù)據(jù)庫）數(shù)據(jù)庫又不能表現(xiàn)數(shù)據(jù)之間的聯(lián)系。同樣屬于NoSQL范疇的圖數(shù)據(jù)庫是以圖的結構形式來存儲數(shù)據(jù)的，它所存儲的就是聯(lián)系的數(shù)據(jù)，是關聯(lián)數(shù)據(jù)本身。
然而關聯(lián)數(shù)據(jù)中的聯(lián)系本來就很復雜，若要在關系型數(shù)據(jù)庫中使用結構化形式來表現(xiàn)這種聯(lián)系，則一般不能直接表示，處理起來既煩瑣又費事，并且隨著數(shù)據(jù)的不斷增長，其訪問性能將日趨下降。無數(shù)的開發(fā)人員和數(shù)據(jù)庫管理人員都或多或少地使用過關系型數(shù)據(jù)庫，在其應用的規(guī)模化進展過程中，對于數(shù)據(jù)庫的性能優(yōu)化往往捉襟見肘、陷入窘境。圖數(shù)據(jù)庫沒有模式結構的定義，也不需要這些定義，它使用非結構化的方式來存儲關聯(lián)數(shù)據(jù)，所以能夠直接表現(xiàn)數(shù)據(jù)的關聯(lián)特性。
圖數(shù)據(jù)庫的發(fā)展趨勢
在眾多不同的數(shù)據(jù)模型里，關系數(shù)據(jù)模型自20世紀80年代就處于統(tǒng)治地位，而且出現(xiàn)了不少巨頭，如Oracle、MySQL，它們也被稱為：關系數(shù)據(jù)庫管理系統(tǒng)（RDBMS）。然而，隨著關系數(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ī)模興起和繁榮而變得越加緊迫。而在應對這些趨勢時，關系數(shù)據(jù)庫產(chǎn)生了更多的不適應性，從而導致大量解決這些問題中某些特定方面的不同技術出現(xiàn)，它們可以與現(xiàn)有RDBMS相互配合或代替它們。過去的幾年間，出現(xiàn)了大量新型數(shù)據(jù)庫，它們被統(tǒng)稱為NoSQL數(shù)據(jù)庫。其中圖數(shù)據(jù)庫從最近十年的表現(xiàn)來看已經(jīng)成為關注度最高，也是發(fā)展趨勢最明顯的數(shù)據(jù)庫類型。
1234下一頁>（免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產(chǎn)權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）
