最近我在用圖形數(shù)據(jù)庫來完成對一個初創(chuàng)項目的支持。在使用過程中覺得這種圖形數(shù)據(jù)庫實際上挺有意思的。因此在這里給大家做一個簡單的介紹。

NoSQL數(shù)據(jù)庫相信大家都聽說過。它們常常可以用來處理傳統(tǒng)的關(guān)系型數(shù)據(jù)庫所難以解決的一系列問題。通常情況下，這些NoSQL數(shù)據(jù)庫分為Graph，Document，Column Family以及Key-Value Store等四種。這四種類型的數(shù)據(jù)庫分別使用了不同的數(shù)據(jù)結(jié)構(gòu)來記錄數(shù)據(jù)。因此它們所適用的場景也不盡相同。

　　其中最為特別的便是圖形數(shù)據(jù)庫了。可以說，它和其它的一系列NoSQL數(shù)據(jù)庫非常不同：豐富的關(guān)系表示，完整的事務(wù)支持，卻沒有一個純正的橫向擴展解決方案。

　　在本文中，我們就將對業(yè)界非常流行的圖形數(shù)據(jù)庫Neo4J進行簡單的介紹。

?

圖形數(shù)據(jù)庫簡介

　　相信您和我一樣，在使用關(guān)系型數(shù)據(jù)庫時常常會遇到一系列非常復(fù)雜的設(shè)計問題。例如一部電影中的各個演員常常有主角配角之分，還要有導(dǎo)演，特效等人員的參與。通常情況下這些人員常常都被抽象為Person類型，對應(yīng)著同一個數(shù)據(jù)庫表。同時一位導(dǎo)演本身也可以是其它電影或者電視劇的演員，更可能是歌手，甚至是某些影視公司的投資者（沒錯，我這個例子的確是以趙薇為模板的）。而這些影視公司則常常是一系列電影，電視劇的資方。這種彼此關(guān)聯(lián)的關(guān)系常常會非常復(fù)雜，而且在兩個實體之間常常同時存在著多個不同的關(guān)系：

　　在嘗試使用關(guān)系型數(shù)據(jù)庫對這些關(guān)系進行建模時，我們首先需要建立表示各種實體的一系列表：表示人的表，表示電影的表，表示電視劇的表，表示影視公司的表等等。這些表常常需要通過一系列關(guān)聯(lián)表將它們關(guān)聯(lián)起來：通過這些關(guān)聯(lián)表來記錄一個人到底參演過哪些電影，參演過哪些電視劇，唱過哪些歌，同時又是哪些公司的投資方。同時我們還需要創(chuàng)建一系列關(guān)聯(lián)表來記錄一部電影中哪些人是主角，哪些人是配角，哪個人是導(dǎo)演，哪些人是特效等。可以看到，我們需要大量的關(guān)聯(lián)表來記錄這一系列復(fù)雜的關(guān)系。在更多實體引入之后，我們將需要越來越多的關(guān)聯(lián)表，從而使得基于關(guān)系型數(shù)據(jù)庫的解決方案繁瑣易錯。

　　這一切的癥結(jié)主要在于關(guān)系型數(shù)據(jù)庫是以為實體建模這一基礎(chǔ)理念設(shè)計的。該設(shè)計理念并沒有提供對這些實體間關(guān)系的直接支持。在需要描述這些實體之間的關(guān)系時，我們常常需要創(chuàng)建一個關(guān)聯(lián)表以記錄這些數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系，而且這些關(guān)聯(lián)表常常不用來記錄除外鍵之外的其它數(shù)據(jù)。也就是說，這些關(guān)聯(lián)表也僅僅是通過關(guān)系型數(shù)據(jù)庫所已有的功能來模擬實體之間的關(guān)系。這種模擬導(dǎo)致了兩個非常糟糕的結(jié)果：數(shù)據(jù)庫需要通過關(guān)聯(lián)表間接地維護實體間的關(guān)系，導(dǎo)致數(shù)據(jù)庫的執(zhí)行效能低下；同時關(guān)聯(lián)表的數(shù)量急劇上升。

　　這種執(zhí)行效能到底低下到什么程度呢？就以建立人和電影之間的投資關(guān)系為例。一個使用關(guān)聯(lián)表的設(shè)計常常如下所示：

　　如果現(xiàn)在我們想要通過該關(guān)系找到一部電影的所有投資人，關(guān)系型數(shù)據(jù)庫常常會執(zhí)行哪些操作呢？首先，在關(guān)聯(lián)表中執(zhí)行一個Table Scan操作（假設(shè)沒有得到索引支持），以找到所有film域的值與目標電影id相匹配的記錄。接下來，通過這些記錄中的person域所記錄的Person的主鍵值來從Person表中找到相應(yīng)的記錄。如果記錄較少，那么這步就會使用Clustered Index Seek操作（假設(shè)是使用該運算符）。整個操作的時間復(fù)雜度將變?yōu)镺(nlogn)：

　　可以看到，通過關(guān)聯(lián)表組織的關(guān)系在運行時的性能并不是很好。如果我們所需要操作的數(shù)據(jù)集包含了非常多的關(guān)系，而且主要是在對這些關(guān)系進行操作，那么可以想象到關(guān)系數(shù)據(jù)庫的性能將變得有多差。

　　除了性能之外，關(guān)聯(lián)表數(shù)量的管理也是一個非常讓人頭疼的問題。剛剛我們僅僅是舉了一個具有四個實體的例子：人，電影，電視劇，影視公司。現(xiàn)實生活中的例子可不是這么簡單。在一些場景下，我們常常需要對更多的實體進行建模，從而完整地描述某一領(lǐng)域內(nèi)的關(guān)聯(lián)關(guān)系。這種關(guān)聯(lián)關(guān)系所涵蓋的可能包含影視公司的控股關(guān)系，各控股公司之間復(fù)雜的持股關(guān)系以及各公司之間的借貸款情況及擔(dān)保關(guān)系等，更可能是人之間的關(guān)系，人與各個品牌之間的代言關(guān)系，各個品牌與所屬公司之間的關(guān)系等。

　　可以看到，在需要描述大量關(guān)系時，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫已經(jīng)不堪重負。它所能承擔(dān)的是較多實體但是實體間關(guān)系略顯簡單的情況。而對于這種實體間關(guān)系非常復(fù)雜，常常需要在關(guān)系之中記錄數(shù)據(jù)，而且大部分對數(shù)據(jù)的操作都與關(guān)系有關(guān)的情況，原生支持了關(guān)系的圖形數(shù)據(jù)庫才是正確的選擇。它不僅僅可以為我們帶來運行性能的提升，更可以大大提高系統(tǒng)開發(fā)效率，減少維護成本。

　　在一個圖形數(shù)據(jù)庫中，數(shù)據(jù)庫的最主要組成主要有兩種，結(jié)點集和連接結(jié)點的關(guān)系。結(jié)點集就是圖中一系列結(jié)點的集合，比較接近于關(guān)系數(shù)據(jù)庫中所最常使用的表。而關(guān)系則是圖形數(shù)據(jù)庫所特有的組成。因此對于一個習(xí)慣于使用關(guān)系型數(shù)據(jù)庫開發(fā)的人而言，如何正確地理解關(guān)系則是正確使用圖形數(shù)據(jù)庫的關(guān)鍵。

　　注：這里的結(jié)點集是我自己的翻譯。在Neo4J官方文檔中，其被稱為label。原文為：A label is a named graph construct that is used to group nodes into sets; all nodes labeled with the?same label belongs to the same set。我個人覺得生硬地取名為標簽反而容易讓別人混淆，所以選取了“group nodes into sets”的意譯，也好讓label和node，即結(jié)點集和結(jié)點之間的關(guān)系能夠更好地對應(yīng)。

　　但是不用擔(dān)心，在了解了圖形數(shù)據(jù)庫對數(shù)據(jù)進行抽象的方式之后，您就會覺得這些數(shù)據(jù)抽象方式實際上和關(guān)系型數(shù)據(jù)庫還是非常接近的。簡單地說，每個結(jié)點仍具有標示自己所屬實體類型的標簽，也既是其所屬的結(jié)點集，并記錄一系列描述該結(jié)點特性的屬性。除此之外，我們還可以通過關(guān)系來連接各個結(jié)點。因此各個結(jié)點集的抽象實際上與關(guān)系型數(shù)據(jù)庫中的各個表的抽象還是有些類似的：

　　但是在表示關(guān)系的時候，關(guān)系型數(shù)據(jù)庫和圖形數(shù)據(jù)庫就有很大的不同了：

　　從上圖中可以看到，在需要表示多對多關(guān)系時，我們常常需要創(chuàng)建一個關(guān)聯(lián)表來記錄不同實體的多對多關(guān)系，而且這些關(guān)聯(lián)表常常不用來記錄信息。如果兩個實體之間擁有多種關(guān)系，那么我們就需要在它們之間創(chuàng)建多個關(guān)聯(lián)表。而在一個圖形數(shù)據(jù)庫中，我們只需要標明兩者之間存在著不同的關(guān)系，例如用DirectBy關(guān)系指向電影的導(dǎo)演，或用ActBy關(guān)系來指定參與電影拍攝的各個演員。同時在ActBy關(guān)系中，我們更可以通過關(guān)系中的屬性來表示其是否是該電影的主演。而且從上面所展示的關(guān)系的名稱上可以看出，關(guān)系是有向的。如果希望在兩個結(jié)點集間建立雙向關(guān)系，我們就需要為每個方向定義一個關(guān)系。

　　也就是說，相對于關(guān)系數(shù)據(jù)庫中的各種關(guān)聯(lián)表，圖形數(shù)據(jù)庫中的關(guān)系可以通過關(guān)系能夠包含屬性這一功能來提供更為豐富的關(guān)系展現(xiàn)方式。因此相較于關(guān)系型數(shù)據(jù)庫，圖形數(shù)據(jù)庫的用戶在對事物進行抽象時將擁有一個額外的武器，那就是豐富的關(guān)系：

　　因此在為圖形數(shù)據(jù)庫定義數(shù)據(jù)展現(xiàn)時，我們應(yīng)該以一種更為自然的方式來對這些需要展現(xiàn)的事物進行抽象：首先為這些事物定義其所對應(yīng)的結(jié)點集，并定義該結(jié)點集所具有的各個屬性。接下來辨識出它們之間的關(guān)系并創(chuàng)建這些關(guān)系的相應(yīng)抽象。

　　因此一個圖形數(shù)據(jù)庫中所承載的數(shù)據(jù)最終將有類似于下圖所示的結(jié)構(gòu)：

?

設(shè)計一個優(yōu)質(zhì)的圖

　　在了解了圖形數(shù)據(jù)庫的基礎(chǔ)知識之后，我們就要開始嘗試使用圖形數(shù)據(jù)庫了。首先我們要搞清楚一個問題，那就是如何為我們的圖形數(shù)據(jù)庫定義一個設(shè)計良好的圖？實際上這并不困難，您只需要了解圖數(shù)據(jù)庫設(shè)計時所使用的一系列要點即可。

　　首先就是，分清圖中結(jié)點集，結(jié)點以及關(guān)系之間的相互聯(lián)系。在以往的基于關(guān)系型數(shù)據(jù)庫的設(shè)計中，我們常常會使用一個表來抽象一類事物。如對于人這個概念，我們常常會抽象出一個表，并在表中添加表示兩個人的記錄，Alice和Bob：

　　而在圖數(shù)據(jù)庫中，這里對應(yīng)著兩個概念：結(jié)點集和結(jié)點。在通常情況下，圖形數(shù)據(jù)庫中的數(shù)據(jù)展示并不使用結(jié)點集，而是獨立的結(jié)點：

　　而如果需要在圖中添加對書籍的支持，那么這些書籍將仍然被表示為一個結(jié)點：

　　也就是說，雖然在一個圖數(shù)據(jù)庫中常常擁有結(jié)點集的概念，但是它已經(jīng)不再作為圖數(shù)據(jù)庫的最重要抽象方式了。甚至從某些圖形數(shù)據(jù)庫已經(jīng)允許軟件開發(fā)人員使用Schemaless結(jié)點這一點上來看，它們已經(jīng)將結(jié)點集的概念弱化了。反過來，我們思考的角度就應(yīng)該是結(jié)點個體，以及這些個體之間所存在的一系列關(guān)系。

　　那么我們是不是可以隨便定義各個結(jié)點所具有的數(shù)據(jù)呢？不是的。這里最為常用的一個準則就是：Schemaless這種靈活度能為你帶來好處。例如相較于強類型語言，弱類型語言可以為軟件開發(fā)人員帶來更大的開發(fā)靈活度，但是其維護性和嚴謹性常常不如強類型語言。同樣地，在使用Schemaless結(jié)點時也要兼顧靈活性和維護性。

　　這樣我們就可以在結(jié)點中添加多種多樣的關(guān)系，而不用像在關(guān)系型數(shù)據(jù)庫中那樣需要擔(dān)心是否需要通過更改數(shù)據(jù)庫的Schema來記錄一些外鍵。這進而允許軟件開發(fā)人員在各結(jié)點間添加多種多樣的關(guān)系：

　　因此在一個圖形數(shù)據(jù)庫中，結(jié)點集這個概念已經(jīng)不是最重要的那一類概念了。例如在某些圖形數(shù)據(jù)庫中，各個結(jié)點的ID并不是按照結(jié)點集來組織的，而是根據(jù)結(jié)點的創(chuàng)建順序來賦予的。在調(diào)試時您可能會發(fā)現(xiàn)，某個結(jié)點集內(nèi)的第一個結(jié)點的ID是1，第二個結(jié)點的ID就是3了。而具有2這個ID的結(jié)點則處于另一個結(jié)點集中。

　　那么我們應(yīng)該如何為業(yè)務(wù)邏輯定義一個合適的圖呢？簡單地說，單一事物應(yīng)該被抽象為一個結(jié)點，而同一類型的結(jié)點被記錄在同一個結(jié)點集中。結(jié)點集內(nèi)各結(jié)點所包含的數(shù)據(jù)可能有一些不同，如一個人可能有不同的職責(zé)并由此通過不同的關(guān)系和其它結(jié)點關(guān)聯(lián)。例如一個人既可能是演員，可能是導(dǎo)演，也可能是演員兼導(dǎo)演。在關(guān)系型數(shù)據(jù)庫中，我們可能需要為演員和導(dǎo)演建立不同的表。而在圖形數(shù)據(jù)庫中，這三種類型的人都是人這個結(jié)點集內(nèi)的數(shù)據(jù)，而不同的僅僅是它們通過不同的關(guān)系連接到不同的結(jié)點上了而已。也就是說，在圖形數(shù)據(jù)庫中，結(jié)點集并不會像關(guān)系型數(shù)據(jù)庫中的表一樣粒度那么小。

　　一旦抽象出了各個結(jié)點集，我們就需要找出這些結(jié)點之間所可能擁有的關(guān)系。這些關(guān)系不僅僅是跨結(jié)點集的。有時候，這些關(guān)系是同一結(jié)點集內(nèi)的結(jié)點之間的關(guān)系，甚至是同一結(jié)點指向自身的關(guān)系：

　　這些關(guān)系通常都具有一個起點和終點。也就是說，圖形數(shù)據(jù)庫中的關(guān)系常常是有向的。如果希望在兩個結(jié)點之間創(chuàng)建一個相互關(guān)系，如Alice和Bob彼此相識，我們就需要在他們之間創(chuàng)建兩個KNOW_ABOUT關(guān)系。其中一個關(guān)系由Alice指向Bob，而另一個關(guān)系則由Bob指向Alice：

　　需要注意的一點就是，雖然說圖形數(shù)據(jù)庫中的關(guān)系是單向的，但是在一些圖形數(shù)據(jù)庫的實現(xiàn)中，如Neo4J，我們不僅僅可以查找到從某個結(jié)點所發(fā)出的關(guān)系，也可以找到指向某個結(jié)點的各個關(guān)系。也就是說，雖然圖中的關(guān)系是單向的，但是關(guān)系在起點和終點都可以被查找到。

?

在項目中使用Neo4J

　　OK，在大概了解了圖形數(shù)據(jù)庫的一些基礎(chǔ)知識之后，我們就將以Neo4J為例講解如何使用一個圖形數(shù)據(jù)庫了。Neo4J是Neo Technology所提供的開源圖形數(shù)據(jù)庫。其按照上面所介紹的結(jié)點/關(guān)系模型組織數(shù)據(jù)，并擁有以下一系列特性：

• 對事務(wù)的支持。Neo4J強制要求每個對數(shù)據(jù)的更改都需要在一個事務(wù)之內(nèi)完成，以保證數(shù)據(jù)的一致性。
• 強大的圖形搜索能力。Neo4J允許用戶通過Cypher語言來操作數(shù)據(jù)庫。該語言是特意為操作圖形數(shù)據(jù)庫設(shè)計的，因此其可以非常高效地操作圖形數(shù)據(jù)庫。同時Neo4J也提供了面向當前市場一系列流行語言的客戶端，以供使用這些語言的開發(fā)人員能夠快速地對Neo4J進行操作。除此之外，一些項目，如Spring Data Neo4J，也提供了一系列非常簡單明了的數(shù)據(jù)操作方式，使得用戶上手變得更為容易。
• 具有一定的橫向擴展能力。由于圖中的一個結(jié)點常常具有和其它結(jié)點相關(guān)聯(lián)的關(guān)系，因此像一系列Sharding解決方案那樣對圖進行切割常常并不現(xiàn)實。因此Neo4J當前所提供的橫向擴展方案主要是通過Read Replica進行的讀寫分割。反過來，由于單個Neo4J實例可以存儲幾十億個結(jié)點及關(guān)系，因此對于一般的企業(yè)級應(yīng)用，這種橫向擴展能力已經(jīng)足夠了。

　　好，現(xiàn)在我們就來看一個通過Cypher來創(chuàng)建并操作圖形數(shù)據(jù)庫的例子（來自http://neo4j.com/developer/guide-data-modeling/）：

1 // 創(chuàng)建Sally這個Person類型的結(jié)點，該結(jié)點的name屬性為Sally，age屬性為32 2 CREATE (sally:Person { name: 'Sally', age: 32 }) 3 4 // 創(chuàng)建John結(jié)點 5 CREATE (john:Person { name: 'John', age: 27 }) 6 7 // 創(chuàng)建Graph Databases一書所對應(yīng)的結(jié)點 8 CREATE (gdb:Book { title: 'Graph Databases', 9 authors: ['Ian Robinson', 'Jim Webber'] }) 10 11 // 在Sally和John之間建立朋友關(guān)系，這里的since值應(yīng)該是timestamp。請自行回憶各位的日期是如何在關(guān)系數(shù)據(jù)庫中記錄的~~~ 12 CREATE (sally)-[:FRIEND_OF { since: 1357718400 }]->(john) 13 14 // 在Sally和Graph Databases一書之間建立已讀關(guān)系 15 CREATE (sally)-[:HAS_READ { rating: 4, on: 1360396800 }]->(gdb) 16 17 // 在John和Graph Databases一書之間建立已讀關(guān)系 18 CREATE (john)-[:HAS_READ { rating: 5, on: 1359878400 }]->(gdb)

　　該段語句創(chuàng)建了三個結(jié)點：Person結(jié)點Sally和John，以及Book結(jié)點gdb。同時還指定了它們之間的關(guān)系：

注：原圖來自http://neo4j.com/developer/guide-data-modeling/

想節(jié)省時間花在有用的地方，但是為了完整性不得不寫

　　這里有一點需要注意的地方，那就是關(guān)系是單向的。如果希望建立一個雙向的關(guān)系，就像上面Sally和John互為朋友關(guān)系那樣，我們按理來說應(yīng)該需要重復(fù)執(zhí)行創(chuàng)建關(guān)系的過程。由于我沒有試過最新版本的Neo4J（因為它最近有一個破壞了后向兼容性的更改，我們暫時沒有辦法升級Neo4J，也就沒有辦法確認上面的代碼是不是少創(chuàng)建了一次FRIEND_OF），因此請讀者注意。如果有誰實驗了，請將結(jié)果添加到Comment中，感激不盡。

　　有了數(shù)據(jù)，我們就可以對數(shù)據(jù)進行操作了。雖然Cypher和SQL操作的是不同的數(shù)據(jù)結(jié)構(gòu)，但是他們的語法結(jié)構(gòu)還是非常相似的。例如下面的語句就用來獲得Sally和John是什么時候成為朋友的（來自http://neo4j.com/developer/guide-data-modeling/）：

1 MATCH (sally:Person { name: 'Sally' }) 2 MATCH (john:Person { name: 'John' }) 3 MATCH (sally)-[r:FRIEND_OF]-(john) 4 RETURN r.since as friends_since

　　而且還有一些更復(fù)雜的語法。如下面的操作就用來判斷Sally和John誰先讀了《Graph Databases》一書：

1 MATCH (people:Person) 2 WHERE people.name = 'John' OR people.name = 'Sally' 3 MATCH (people)-[r:HAS_READ]->(gdb:Book { title: 'Graph Databases' }) 4 RETURN people.name as first_reader 5 ORDER BY r.on 6 LIMIT 1

　　當然，誰都不愿意寫SQL，否則Hibernate也發(fā)展不起來。一個當前較為流行的解決方案就是Spring Data Neo4J。通過定義一系列Java類并在其上使用一系列標記，我們就能在系統(tǒng)中使用Neo4J了。現(xiàn)在我們就以3.4.4版本的Spring Data Neo4J為例講解如何對其進行使用。

　　首先，我們需要為將要存入到Neo4J中的數(shù)據(jù)定義相應(yīng)的數(shù)據(jù)類型（來自于http://projects.spring.io/spring-data-neo4j/）：

1 // 通過NodeEntity標記來創(chuàng)建一個需要被存入到Neo4J的數(shù)據(jù)類型 2 @NodeEntity 3 public class Movie { 4 // 通過GraphId標記來指定作為ID的域。如果是新建一個結(jié)點，那么我們需要將該域置空（null）。不知道4.0.0是否還有這個限制 5 @GraphId Long id; 6 7 // 創(chuàng)建針對該域的索引 8 @Indexed(type = FULLTEXT, indexName = "search") 9 String title; 10 11 // 對Person類的直接引用。在保存時，其將會被自動保存到Person結(jié)點集中并保持Movie類對該實例的引用 12 Person director; 13 14 // 通過RelatedTo標記來標示當前集合所引用的各個實體對應(yīng)于當前Movie實例的關(guān)系是ACTS_IN。注意這里標明了方向是INCOMING，也就是說，其方向是從Person指向Movie，也既是Person ACTS_IN Movie。而在Person中，我們同樣可以擁有一個Movie的集合，同樣使用RelatedTo標記使用ACTS_IN關(guān)系，而direction為OUTGOING 15 // 另，RelatedTo和RelatedToVia標記按理來說在4.0.0里已經(jīng)被丟棄了，但是在官方示例中依然被使用 16 @RelatedTo(type="ACTS_IN", direction = INCOMING) 17 Set<Person> actors; 18 19 @RelatedToVia(type = "RATED") 20 Iterable<Rating> ratings; 21 22 // 使用自定義Query讀取數(shù)據(jù) 23 @Query("start movie=node({self}) match 24 movie-->genre<--similar return similar") 25 Iterable<Movie> similarMovies; 26 }

　　接下來，您就可以創(chuàng)建一個用來對剛剛所定義的類型進行CRUD操作的Repository了：

1 // 從GraphRepository接口直接得到對Movie類進行CRUD的功能 2 interface MovieRepository extends GraphRepository<Movie> { 3 // 通過Cypher語句來執(zhí)行特定的操作 4 @Query("start movie={0} match m<-[rating:RATED]-user 5 return rating") 6 Iterable<Rating> getRatings(Movie movie); 7 8 // 和Spring Data JPA一樣，可以通過特定的規(guī)則組合函數(shù)名來添加篩選條件 9 Iterable<Person> findByActorsMoviesActorName(name) 10 }

　　最后我們需要在Spring的配置文件中指定這些組成所在的位置：

1 <neo4j:config storeDirectory="target/graph.db" base-package="com.example.neo4j.entity"/> 2 <neo4j:repositories base-package="com.example.neo4j.repository" />

?

Neo4J集群

　　OK，在了解了如何使用Neo4J之后，下一步要考慮的就是如何通過搭建一個Neo4J集群來提供一個具有高可用性，高吞吐量的解決方案了。首先您要知道的是，和其它NoSQL數(shù)據(jù)庫所提供的近乎無限的橫向擴展能力相比，Neo4J集群實際上是有一定限制的。為了能更好地理解這些限制，就讓我們首先看一看Neo4J集群的架構(gòu)以及它到底是如何工作的：

　　上圖展示了一個由三個Neo4J結(jié)點所組成的Master-Slave集群。通常情況下，每個Neo4J集群都包含一個Master和多個Slave。該集群中的每個Neo4J實例都包含了圖中的所有數(shù)據(jù)。這樣任何一個Neo4J實例的失效都不會導(dǎo)致數(shù)據(jù)的丟失。集群中的Master主要負責(zé)數(shù)據(jù)的寫入，接下來Slave則會將Master中的數(shù)據(jù)更改同步到自身。如果一個寫入請求到達了Slave，那么該Slave也將會就該請求與Master通信。此時該寫入請求將首先被Master執(zhí)行，再異步地將數(shù)據(jù)更新到各個Slave中。所以在上圖中，您可以看到表示數(shù)據(jù)寫入方式的紅線有從Master到Slave，也有從Slave到Master，但是并沒有從Slave到Slave。而所有這一切都是通過Transaction Propagation組成來協(xié)調(diào)完成的。

　　有些讀者可能已經(jīng)注意到了：Neo4J集群中數(shù)據(jù)的寫入是通過Master來完成的，那是不是Master會變成系統(tǒng)的寫入瓶頸呢？答案是幾乎不會。首先是圖數(shù)據(jù)修改的復(fù)雜性導(dǎo)致其并不會像棧，數(shù)組等數(shù)據(jù)類型那樣容易被修改。在修改一個圖的時候，我們不但需要修改圖結(jié)點本身，還要維護各個關(guān)系，本身就是一個比較復(fù)雜的過程，對用戶而言也是較難理解的。因此對圖所進行的操作也常常是讀比寫多很多。同時Neo4J內(nèi)部還有一個寫隊列，可以用來暫時緩存向Neo4J實例的寫入操作，從而使得Neo4J能夠處理突然到來的大量寫入操作。而在最壞的情況就是Neo4J集群需要面對持續(xù)的大量的寫入操作。在這種情況下，我們就需要考慮Neo4J集群的縱向擴展了，因為此時橫向擴展無益于解決這個問題。

　　反過來，由于數(shù)據(jù)的讀取可以通過集群中的任意一個Neo4J實例來完成，因此Neo4J集群的讀吞吐量可以在理論上做到隨集群中Neo4J實例的個數(shù)線性增長。例如如果一個擁有5個結(jié)點的Neo4J集群可以每秒響應(yīng)500個讀請求，那么再添加一個結(jié)點就可以將其擴容為每秒響應(yīng)600個讀請求。

　　但在請求量非常巨大而且訪問的數(shù)據(jù)分布非常隨機的情況下，另一個問題就可能發(fā)生了，那就是Cache-Miss。Neo4J內(nèi)部使用一個緩存記錄最近所訪問的數(shù)據(jù)。這些緩存數(shù)據(jù)會保存在內(nèi)存中以便快速地響應(yīng)數(shù)據(jù)讀取請求。但是在請求量非常巨大而且所訪問數(shù)據(jù)分布隨機的情況下，Cache-Miss將會持續(xù)地發(fā)生，使得每次對數(shù)據(jù)的讀取都要經(jīng)過磁盤查找來完成，從而大大地降低了Neo4J實例的運行效率。而Neo4J所提供的解決方案被稱為Cache-based Sharding。簡單地說，就是使用同一個Neo4J實例來響應(yīng)一個用戶所發(fā)送的所有需求。其背后的原理也非常簡單，那就是同一個用戶在一段時間內(nèi)所訪問的數(shù)據(jù)常常是類似的。因此將這個用戶的一系列數(shù)據(jù)請求發(fā)送到同一個Neo4J服務(wù)器實例上可以很大程度上降低發(fā)生Cache-Miss的概率。

　　Neo4J數(shù)據(jù)服務(wù)器中的另一個組成Cluster Management則用來負責(zé)同步集群中各個實例的狀態(tài)，并監(jiān)控其它Neo4J結(jié)點的加入和離開。同時其還負責(zé)維護領(lǐng)導(dǎo)選舉結(jié)果的一致性。如果Neo4J集群中失效的結(jié)點個數(shù)超過了集群中結(jié)點個數(shù)的一半，那么該集群將只接受讀取操作，直到有效結(jié)點重新超過集群結(jié)點數(shù)量的一半。

　　在啟動時，一個Neo4J數(shù)據(jù)庫實例將首先嘗試著加入由配置文件所標明的集群。如果該集群存在，那么它將作為一個Slave加入。否則該集群將被創(chuàng)建，并且其將被作為該集群的Master。

　　如果Neo4J集群中的一個Neo4J實例失效了，那么其它Neo4J實例會在短時間內(nèi)探測到該情況并將其標示為失效，直到其重新恢復(fù)到正常狀態(tài)并將數(shù)據(jù)同步到最新。這其中有一個特殊情況，那就是Master失效的情況。在該情況下，Neo4J集群將會通過內(nèi)置的Leader選舉功能選舉出新的Master。

　　在Cluster Management組成的幫助下，我們還可以創(chuàng)建一個Global Cluster。其擁有一個Master Cluster以及多個Slave Cluster。該集群組建方式允許Master Cluster和Slave Cluster處于不同區(qū)域的服務(wù)集群中。這樣就可以允許服務(wù)的用戶訪問距離自己最近的服務(wù)。和Neo4J集群中的Master及Slave實例的關(guān)系類似，數(shù)據(jù)的寫入通常都是在Master Cluster中進行，而Slave Cluster將只負責(zé)提供數(shù)據(jù)讀取服務(wù)。

?

提高Neo4J的性能

　　相信您在上面對Neo4J集群的講解中已經(jīng)看出，Neo4J集群實際上還是有一些限制的。這些限制將可能導(dǎo)致Neo4J集群在總的系統(tǒng)容量，如存儲結(jié)點的數(shù)目或?qū)懲掏铝康缺姸喾矫娲嬖谥欢ǖ钠款i。在《服務(wù)的擴展性》一文中我們曾經(jīng)介紹過，通過縱向擴展，我們同樣可以提高服務(wù)的整體性能。除了通過為Neo4J提供具有更高容量的硬件之外，更有效地使用Neo4J也是縱向擴展的一個重要方法。

　　和SQL Server等數(shù)據(jù)庫所提供的Execution Plan類似，Neo4J也提供了Execution Plan。在執(zhí)行一個請求時，Neo4J將會把這個請求拆解為一系列較小的操作符（Operator）。每個操作符都將執(zhí)行一部分工作，并彼此相互協(xié)作完成對請求的響應(yīng)。與SQL Server的Execution Plan類似，Neo4J的Execution Plan同樣擁有Scan，Seek，Merge，Filter等多種類型的操作。我們可以通過EXPLAIN或PROFILE命令得到一個請求將被如何執(zhí)行的樹形表示。通過查看這些樹形表示，軟件開發(fā)人員能夠了解一個請求在Neo4J中是如何運行的：

　　以下是當前版本的Neo4J所支持的所有操作符：http://neo4j.com/docs/stable/execution-plans.html。

　　有通過Execution Plan調(diào)優(yōu)經(jīng)驗的讀者可能第一眼就看到了一個操作符：Node Index Seek。它的名字直接透露了Neo4J中的另一個調(diào)優(yōu)利器：索引。我們知道，只要查找出的結(jié)果集中記錄的數(shù)據(jù)并不是很多，那么SQL Server中的Clusted Index Seek常常是具有最優(yōu)效率的操作。因此在Neo4J中，我們同樣需要盡量合理地使用索引，從而使得Neo4J所生成的Execution Plan能使用基于索引的一系列操作符。讓我們回憶一下之前展示給大家的按照Spring Data Neo4J方式抽象出的Movie類：

1 @NodeEntity 2 public class Movie { 3 @GraphId Long id; 4 5 @Indexed(type = FULLTEXT, indexName = "search") 6 String title; 7 8 …… 9 }

　　上面的代碼展示了我們應(yīng)該如何通過@Indexed標記來創(chuàng)建一個索引。如果您是直接使用Cypher來操作Neo4J的，那么您可以通過以下語句來創(chuàng)建一個索引：

1 CREATE INDEX ON :Movie(title)

　　而這里有一個和SQL Server略有不一致的地方，那就是對@GraphId標記的理解。在SQL Server中，Primary Key實際上是與索引沒有任何關(guān)聯(lián)的，只是在默認情況下，其常常會被自動地添加一個索引。而在Neo4J中，由@GraphId標記所修飾的域則更像是Neo4J的內(nèi)部實現(xiàn)。Neo4J通過該域所記錄的值執(zhí)行對結(jié)點的訪問，而不是在其上自動地添加了一個索引。

　　還有一個可能非常容易影響Neo4J性能的可能，那就是嘗試使用Neo4J記錄不適合它記錄的數(shù)據(jù)。在本文的一開始我們就已經(jīng)介紹了Neo4J所適合的領(lǐng)域，那就是記錄圖形數(shù)據(jù)，及結(jié)點集和結(jié)點之間的關(guān)系。而對于其它一些類型的數(shù)據(jù)，如用戶的用戶名/密碼對，那就不是圖形數(shù)據(jù)庫所擅長的領(lǐng)域了。在這些情況下，我們應(yīng)該選取合適的數(shù)據(jù)庫來記錄這些數(shù)據(jù)。在一個大型系統(tǒng)中，多種不同類型的數(shù)據(jù)庫相互協(xié)作是經(jīng)常有的事情，所以沒有必要非要將一些本來應(yīng)該由其它類型的數(shù)據(jù)庫所記錄的數(shù)據(jù)硬生生地記錄在Neo4J中。

?

和其它數(shù)據(jù)庫合作

　　在上面我們剛剛提到了不應(yīng)該由Neo4J記錄不適合它記錄的數(shù)據(jù)，以保證Neo4J不被不合理的使用方式拉低其執(zhí)行效率。那么這些數(shù)據(jù)應(yīng)該記錄在哪里呢？答案非常簡單：適合記錄這些數(shù)據(jù)的其它類型的數(shù)據(jù)庫。

　　可能你覺得我這句話是廢話。其實我也這么覺得。而我想在這里介紹的是，如何完成Neo4J和其它數(shù)據(jù)庫之間的集成，從而使它們協(xié)同工作，向用戶提供完整的服務(wù)。對于某些系統(tǒng)，我們可以允許這些數(shù)據(jù)庫之間擁有一定程度的不一致；而對于另外一些系統(tǒng)，我們則需要時刻保證數(shù)據(jù)的一致性。

　　Neo4J所提出支持的技術(shù)方案主要有三種：Event-based Synchronization，Periodic Synchronization以及Periodic Full Export/Import of Data。Event-based Synchronization實際上就是通過同時向基于Neo4J的后臺和基于其它數(shù)據(jù)庫的后臺發(fā)送相同的消息，并由這些后臺完成對數(shù)據(jù)的寫入。Periodic Synchronization則是定時地將一個數(shù)據(jù)庫中對數(shù)據(jù)的更改同步到另一個數(shù)據(jù)庫中。而Periodic Full Export/Import of Data則是通過將一個數(shù)據(jù)庫中的所有數(shù)據(jù)導(dǎo)入到另外一個數(shù)據(jù)庫中的方式來完成的。

　　這三種解決方案都是用來處理Neo4J所記錄的數(shù)據(jù)與其它數(shù)據(jù)庫相同的情況。而更為常見的情況則是，Neo4J記錄實體關(guān)系比較復(fù)雜的圖，其它數(shù)據(jù)庫則用來記錄具有其它類型表現(xiàn)形式的數(shù)據(jù)。Neo4J和這些數(shù)據(jù)庫之間的數(shù)據(jù)只有一部分交集，而每個數(shù)據(jù)庫都擁有自己所特有的數(shù)據(jù)。針對這種情況的處理方法則常常是多步提交。例如在一個交友網(wǎng)站中，用戶可以在頁面上完成自身賬戶的設(shè)置，如用戶名，密碼等，并可以在下一步添加好友界面中添加一系列好友以及有關(guān)于該好友的注釋。那么在該系統(tǒng)中，用戶自身的賬戶設(shè)置就可能記錄在關(guān)系型數(shù)據(jù)庫中，而有關(guān)好友的相關(guān)信息則記錄在圖形數(shù)據(jù)庫中。如果將這兩步中的所有信息作為一個請求發(fā)送到后臺，那么就可能出現(xiàn)在某個數(shù)據(jù)庫上成功保存而在另一個數(shù)據(jù)庫上保存失敗的情況。為了避免這種情況，我們就需要將填充這兩部分資料的信息分為兩個頁面，而在每個頁面下部提供一個”保存并進行下一步”的按鈕。這樣如果第一步設(shè)置賬戶的步驟無法正常保存，那么用戶就沒有辦法進行下一步添加朋友的操作。而在添加朋友這步中，如果圖形數(shù)據(jù)庫無法正常保存，那么我們將可以明確地告訴用戶添加朋友失敗，從而允許用戶重試。

　　其實很多時候，跨不同數(shù)據(jù)庫保存數(shù)據(jù)的問題都可以通過調(diào)整設(shè)計的方式來解決，況且這些數(shù)據(jù)庫所記錄的數(shù)據(jù)常常具有非常不同的數(shù)據(jù)結(jié)構(gòu)。因此就用戶來說，分成多步提交常常是一個非常自然的使用方式。

?

轉(zhuǎn)載請注明原文地址并標明轉(zhuǎn)載：http://www.cnblogs.com/loveis715/p/5277051.html

商業(yè)轉(zhuǎn)載請事先與我聯(lián)系：silverfox715@sina.com

公眾號一定幫忙別標成原創(chuàng)，因為協(xié)調(diào)起來太麻煩了。。。

轉(zhuǎn)載于:https://www.cnblogs.com/loveis715/p/5277051.html

總結(jié)

以上是生活随笔為你收集整理的图形数据库Neo4J简介的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。