劣勢：

新圖形數(shù)據(jù)庫

可視化工具缺乏（可繼承第三方工具Cytoscape、Gephi等）

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

與傳統(tǒng)關系型數(shù)據(jù)庫相比，圖數(shù)據(jù)庫的優(yōu)勢

優(yōu)秀的查詢性能

相對于關系型數(shù)據(jù)庫，圖數(shù)據(jù)庫產(chǎn)品在設計上避免大量的join操作，提供快速的查詢。圖數(shù)據(jù)庫則天然把關聯(lián)數(shù)據(jù)連接在一起，無需耗時耗內(nèi)存的Join操作，可以保持常數(shù)級時間復雜度。

靈活的數(shù)據(jù)建模和查詢語言，Schema－less

多數(shù)圖數(shù)據(jù)庫沒有預設的schema，借助底層的存儲機制，能夠更加靈活的變更結(jié)構(gòu)

靈活的圖查詢語言，輕松實現(xiàn)復雜關系網(wǎng)絡的分析

靈活的數(shù)據(jù)模型可以適應不斷變化的業(yè)務需求

易于理解，更加敏捷

相對于關系型數(shù)據(jù)庫的二維表格，圖的組織形式更接近于現(xiàn)實世界，易于理解

可以很自然的表達現(xiàn)實世界中的實體及其關聯(lián)關系（對應圖的頂點及邊）

關系型數(shù)據(jù)庫在遍歷關系網(wǎng)絡并抽取信息的能力非常弱，圖數(shù)據(jù)庫則為此而生

基于圖算法提供強大分析能力

PageRank／社區(qū)發(fā)現(xiàn)算法等

圖數(shù)據(jù)庫的功能是傳統(tǒng)關系型數(shù)據(jù)庫的一個拓展，相比較關系型數(shù)據(jù)庫僅支持表結(jié)構(gòu)，圖數(shù)據(jù)支持的圖結(jié)構(gòu)更為靈活。圖數(shù)據(jù)庫在基于圖的數(shù)據(jù)增加、刪除、查詢、修改等方面做了不同于其他數(shù)據(jù)庫的設計。在圖數(shù)據(jù)的操作抽象上，采用基于頂點的視角，比如頂點通過其所有處、邊訪問其鄰接頂點，這一類的操作也是圖數(shù)據(jù)庫系統(tǒng)設計的核心。

圖數(shù)據(jù)庫與關系型數(shù)據(jù)庫優(yōu)劣比對

優(yōu)勢

a） 用戶可以面向?qū)ο蟮乃伎�，用戶使用的每個查詢都有顯式語義；

b） 用戶可以實時更新和查詢圖數(shù)據(jù)庫；

c） 圖數(shù)據(jù)庫可以靈活應對海量的關系變化，如增加刪除關系、實體等；

d） 圖數(shù)據(jù)庫有利于實時的大數(shù)據(jù)挖掘結(jié)果可視化。

劣勢

a） 不適合記錄大量基于事件的數(shù)據(jù)（例如日志條目）；

b） 二進制數(shù)據(jù)存儲。

c） 并發(fā)性能要求高的項目。

d） 目前相關圖查詢語言比較多，尚未有很好統(tǒng)一。

e） 圖數(shù)據(jù)庫相關的一些書籍文檔偏少，相關生態(tài)還在不斷完善。

圖數(shù)據(jù)庫在處理關聯(lián)關系上具有完全的優(yōu)勢，但是在一些場景下，圖數(shù)據(jù)庫并不能完全代替關系型數(shù)據(jù)庫。

圖數(shù)據(jù)庫在處理關聯(lián)數(shù)據(jù)時三個技術優(yōu)勢

1、性能方面：

隨著數(shù)據(jù)量的增多和關聯(lián)深度的增加，傳統(tǒng)關系型數(shù)據(jù)庫受制于檢索時需要多個表之間連接操作，數(shù)據(jù)寫入時也需考慮外鍵約束，從而導致較大的額外開銷，產(chǎn)生嚴重的性能問題。而圖模型固有的數(shù)據(jù)索引結(jié)構(gòu)，使得它的數(shù)據(jù)查詢與分析速度更快。在關聯(lián)關系的處理上，用關系型數(shù)據(jù)庫處理不可避免要用到表的JOIN操作，對性能的影響較大；而圖數(shù)據(jù)庫則是類指針直接跳轉(zhuǎn)訪問，更高效的操作關聯(lián)數(shù)據(jù)，比關系型數(shù)據(jù)庫有2到4個數(shù)量級的性能提升。

2、靈活度方面：

圖數(shù)據(jù)庫有非常靈活的數(shù)據(jù)模型，使用者可以根據(jù)業(yè)務變化隨時調(diào)整數(shù)據(jù)模型，比如任意添加或刪除頂點、邊，擴充或者縮小圖模型這些都可以輕松實現(xiàn)，這種頻繁的 Schema 更改在關系型數(shù)據(jù)庫上不能到很好的支持�，F(xiàn)實中，項目的進程往往是不斷演進的。數(shù)據(jù)的內(nèi)容甚至數(shù)據(jù)格式也會不斷發(fā)生變化。在關系型數(shù)據(jù)庫中，這意味著表結(jié)構(gòu)的變化，或者多個新表的建立，對源數(shù)據(jù)的改動非常大。而在圖數(shù)據(jù)庫里，僅需添加新的頂點、邊、屬性，設置為對應的類型即可。從本質(zhì)上說，一個表代表一個類型的數(shù)據(jù)，一個頂點代表一個特定的數(shù)據(jù)，意味著關系數(shù)據(jù)庫更關注數(shù)據(jù)的類型，而圖數(shù)據(jù)庫更關注數(shù)據(jù)的個體，識別其關聯(lián)關系。

3、敏捷度方面：

圖數(shù)據(jù)庫的圖模型非常直觀，支持測試驅(qū)動開發(fā)模式，每次構(gòu)建時可進行功能測試和性能測試，符合當今最流行的敏捷開發(fā)需求，對于提高生產(chǎn)和交付效率也有一定幫助。使用圖（或者網(wǎng)）的方式來表達現(xiàn)實世界的關系更加直接、自然，在萬物互聯(lián)的物聯(lián)網(wǎng)時代尤為突出。如果采用關系型數(shù)據(jù)，先將人物建表，再將關系建表，最后將數(shù)據(jù)進行映射，需要高度的抽象思維。在圖數(shù)據(jù)上進行分析查詢時，也可以直觀地通過點邊連接的拓撲，交互式找到想要的數(shù)據(jù)，不需要具備任何的專業(yè)知識。

傳統(tǒng)關系數(shù)據(jù)庫的性能問題

性能問題的本質(zhì)在于數(shù)據(jù)分析面臨的數(shù)據(jù)量，假如只查詢幾十個節(jié)點或者更少的內(nèi)容，這種操作是完全不需要考慮數(shù)據(jù)庫性能優(yōu)化的，但當節(jié)點數(shù)據(jù)從幾百個變成幾百萬個甚至幾千萬個后，數(shù)據(jù)庫性能就成為了整個產(chǎn)品設計的過程中最需考慮的因素之一。

在數(shù)據(jù)量這么大的場景中，使用傳統(tǒng) SQL 會產(chǎn)生很大的性能問題，原因主要有兩個：

1、大量 JOIN 操作帶來的開銷：

之前的查詢語句使用了大量的 JOIN 操作來找到需要的結(jié)果。而大量的 JOIN 操作在數(shù)據(jù)量很大時會有巨大的性能損失，因為數(shù)據(jù)本身是被存放在指定的地方，查詢本身只需要用到部分數(shù)據(jù)，但是 JOIN 操作本身會遍歷整個數(shù)據(jù)庫，這樣就會導致查詢效率低到讓人無法接受。

2、反向查詢帶來的開銷：

查詢單個經(jīng)理的下屬不需要多少開銷，但是如果我們要去反向查詢一個員工的老板，使用表結(jié)構(gòu)，開銷就會變得非常大。表結(jié)構(gòu)設計得不合理，會對后續(xù)的分析、推薦系統(tǒng)產(chǎn)生性能上的影響。比如，當關系從＿老板 －＞ 員工 變成 ＿用戶 －＞ 產(chǎn)品，如果不支持反向查詢，推薦系統(tǒng)的實時性就會大打折扣，進而帶來經(jīng)濟損失。

圖數(shù)據(jù)庫和關系型數(shù)據(jù)庫性能比較

如圖所見，傳統(tǒng)關系型數(shù)據(jù)庫可以非常好地處理深度為2和3的查詢。join操作在關系型數(shù)據(jù)庫世界中很常見，大多數(shù)數(shù)據(jù)庫都是如此設計，在某些特定列上使用索引相關也能幫助最大化join操作的性能。然而，當深度達到4和5時，您會看到性能顯著下降：一個涉及4個join的查詢需要10秒以上才能完成，而在深度為5時更花了太長時間，超過一分半鐘，雖然計數(shù)結(jié)果沒有改變。這恰恰說明了在對圖結(jié)構(gòu)數(shù)據(jù)建模時關系型數(shù)據(jù)庫的局限性：深度圖遍歷需要多個join操作，關系數(shù)據(jù)庫通常并不擅長這種處理。

但是圖數(shù)據(jù)庫，可以看見，除了最簡單的查詢，圖數(shù)據(jù)庫在其他查詢的性能表現(xiàn)上都是明顯更好的那一個。只有在尋找朋友的朋友時（深度為2），關系型數(shù)據(jù)庫性能可與圖數(shù)據(jù)庫遍歷的性能相媲美。在深度為3時的遍歷比關系型數(shù)據(jù)庫快4倍。在深度為4，結(jié)果則要好五個數(shù)量級。深度為5時，圖數(shù)據(jù)庫結(jié)果的速度甚至要比關系型數(shù)據(jù)庫要快1000萬倍。關系型數(shù)據(jù)庫查詢性能下降如此之快正是由于，join操作需要對全部數(shù)據(jù)進行笛卡爾積運算，其中大部分的數(shù)據(jù)我們并不需要。

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

當前這種任務擴展方式僅僅只是給開發(fā)人員提供了便利，但是用戶仍然很難擴展自己的任務，因此后續(xù)會考慮將任務擴展的能力做成平臺功能的一部分提供給用戶使用。

我們以Apache Atlas為例，探索圖數(shù)據(jù)庫在數(shù)據(jù)資產(chǎn)可視化方面的應用。

Apache Atlas是Hadoop的數(shù)據(jù)治理和元數(shù)據(jù)框架。是一組可擴展和可擴展的核心基礎治理服務，使企業(yè)能夠有效，高效地滿足Hadoop中的合規(guī)性要求，并允許與整個企業(yè)數(shù)據(jù)生態(tài)系統(tǒng)集成。