簡介

　　在眾多不同的數(shù)據(jù)模型里，關系數(shù)據(jù)模型自80年代就處于統(tǒng)治地位，而且有不少實現(xiàn)，如Oracle、MySQL和MSSQL，它們也被稱為關系數(shù)據(jù)庫管理系統(tǒng)（RDBMS）。然而，最近隨著關系數(shù)據(jù)庫使用案例的不斷增加，一些問題也暴露了出來，這主要是因為兩個原因：數(shù)據(jù)建模中的一些缺陷和問題，以及在大數(shù)據(jù)量和多服務器之上進行水平伸縮的限制。兩個趨勢讓這些問題引起了全球軟件社區(qū)的重視：

1. 用戶、系統(tǒng)和傳感器產生的數(shù)據(jù)量呈指數(shù)增長，其增長速度因大部分數(shù)據(jù)量集中在象Amazon、Google和其他云服務這樣的分布式系統(tǒng)上而進一步加快。
2. 數(shù)據(jù)內部依賴和復雜度的增加，這一問題因互聯(lián)網、Web2.0、社交網絡，以及對大量不同系統(tǒng)的數(shù)據(jù)源開放和標準化的訪問而加劇。

　　在應對這些趨勢時，關系數(shù)據(jù)庫產生了更多的問題。這導致大量解決這些問題某些特定方面的不同技術的出現(xiàn)，它們可以與現(xiàn)有RDBMS相互配合或代替它們-亦被稱為混合持久化（Polyglot Persistence）。數(shù)據(jù)庫替代品并不是新鮮事物，它們已經以對象數(shù)據(jù)庫（OODBMS）、層次數(shù)據(jù)庫（如LDAP）等形式存在很長時間了。但是，過去幾年間，出現(xiàn)了大量新項目，它們被統(tǒng)稱為NOSQL數(shù)據(jù)庫（NOSQL-databases）

本文旨在介紹圖形數(shù)據(jù)庫（Graph Database）在NOSQL運動里的地位，第二部分則是對Neo4j（一種基于Java的圖形數(shù)據(jù)庫）的簡介。

　　NOSQL環(huán)境

　　NOSQL（Not Only SQL，不限于SQL）是一類范圍非常廣泛的持久化解決方案，它們不遵循關系數(shù)據(jù)庫模型，也不使用SQL作為查詢語言。

　　簡單地講，NOSQL數(shù)據(jù)庫可以按照它們的數(shù)據(jù)模型分成4類：

1. 鍵-值存儲庫（Key-Value-stores）
2. BigTable實現(xiàn)（BigTable-implementations）
3. 文檔庫（Document-stores）
4. 圖形數(shù)據(jù)庫（Graph Database）

　　就Voldemort或Tokyo CabiNET這類鍵/值系統(tǒng)而言，最小的建模單元是鍵-值對。對BigTable的克隆品來講，最小建模單元則是包含不同個數(shù)屬性的元組，至于象CouchDB和MongoDB這樣的文檔庫，最小單元是文檔。圖形數(shù)據(jù)庫則干脆把整個數(shù)據(jù)集建模成一個大型稠密的網絡結構。

　　在此，讓我們深入檢閱NOSQL數(shù)據(jù)庫的兩個有意思的方面：伸縮性和復雜度。

　　1.伸縮性

　　CAP: ACID vs. BASE

　　為了保證數(shù)據(jù)完整性，大多數(shù)經典數(shù)據(jù)庫系統(tǒng)都是以事務為基礎的。這全方位保證了數(shù)據(jù)管理中數(shù)據(jù)的一致性。這些事務特性也被稱為ACID（A代表原子性、C表示一致性、I是隔離性、D則為持久性）。然而，ACID兼容系統(tǒng)的向外擴展已經表現(xiàn)為一個問題。在分布式系統(tǒng)中，高可用性不同方面之間產生的沖突沒有完全得到解決-亦稱CAP法則：

• 強一致性（C）：所有客戶端看到的數(shù)據(jù)是同一個版本，即使是數(shù)據(jù)集發(fā)生了更新-如利用兩階段提交協(xié)議（XA事務），和ACID，
• 高可用性（A）：所有客戶端總能找到所請求數(shù)據(jù)的至少一個版本，即使集群中某些機器已經宕機，
• 分區(qū)容忍性（P）：整個系統(tǒng)保持自己的特征，即使是被部署到不同服務器上的時候，這對客戶端來講是透明的。

　　CAP法則假定向外擴展的3個不同方面中只有兩個可以同時完全實現(xiàn)。

　　為了能處理大型分布式系統(tǒng)，讓我們深入了解所采用的不同CAP特征。

　　很多NOSQL數(shù)據(jù)庫首先已經放寬了對于一致性（C）的要求，以期得到更好的可用性（A）和分區(qū)容忍性（P）。這產生了被稱為BASE（基本（B）可用性（A）、軟狀態(tài)（S）、最終一致性（E））的系統(tǒng)。它們沒有經典意義上的事務，并且在數(shù)據(jù)模型上引入了約束，以支持更好的分區(qū)模式（如Dynamo系統(tǒng)等）。關于CAP、ACID和BASE的更深入討論可以在這篇介紹里找到。

　　2.復雜度

　　蛋白質同源網絡（Protein Homology NETwork），感謝Alex Adai：細胞和分子生物學院-德州大學

　　數(shù)據(jù)和系統(tǒng)的互聯(lián)性增加產生了一種無法用簡單明了或領域無關（domain-independent）方式進行伸縮和自動分區(qū)的稠密數(shù)據(jù)集，甚至連Todd Hoff也提到了這一問題。關于大型復雜數(shù)據(jù)集的可視化內容可以訪問可視化復雜度（Visual Complexity）。

　　關系模型

　　在把關系數(shù)據(jù)模型扔進故紙堆之前，我們不應該忘記關系數(shù)據(jù)庫系統(tǒng)成功的一個原因是遵照E.F. Codd的想法，關系數(shù)據(jù)模型通過規(guī)范化的手段原則上能夠建模任何數(shù)據(jù)結構且沒有信息冗余和丟失。建模完成之后，就可以使用SQL以一種非常強大的方式插入、修改和查詢數(shù)據(jù)。甚至有些數(shù)據(jù)庫，為了插入速度或針對不同使用情況（如OLTP、OLAP、Web應用或報表）的多維查詢（星形模式），對模式實現(xiàn)了優(yōu)化。

　　這只是理論。然而在實踐中，RDBM遇到了前面提到的CAP問題的限制，以及由高性能查詢實現(xiàn)而產生的問題：聯(lián)結大量表、深度嵌套的SQL查詢。其他問題包括伸縮性、隨時間的模式演變，樹形結構的建模，半結構化數(shù)據(jù)，層級和網絡等。

　　關系模型也很難適應當前軟件開發(fā)的方法，如面向對象和動態(tài)語言，這被稱為對象-關系阻抗失配。由此，象Java的Hibernate這樣的ORM層被開發(fā)了出來，而且被應用到這種混合環(huán)境里。它們固然簡化了把對象模型映射到關系數(shù)據(jù)模型的任務，但是沒有優(yōu)化查詢的性能。尤其是半結構化數(shù)據(jù)往往被建模成具有許多列的大型表，其中很多行的許多列是空的（稀疏表），這導致了拙劣的性能。甚至作為替代方法，把這些結構建模成大量的聯(lián)結表，也有問題。因為RDBMS中的聯(lián)結是一種非常昂貴的集合操作。

　　圖形是關系規(guī)范化的一種替代技術

　　看看領域模型在數(shù)據(jù)結構上的方案，有兩個主流學派- RDBMS采用的關系方法和圖-即網絡結構，如語義網用到的。

　　盡管圖結構在理論上甚至可以用RDBMS規(guī)范化，但由于關系數(shù)據(jù)庫的實現(xiàn)特點，對于象文件樹這樣的遞歸結構和象社交圖這樣的網絡結構有嚴重的查詢性能影響。網絡關系上的每次操作都會導致RDBMS上的一次"聯(lián)結"操作，以兩個表的主鍵集合間的集合操作來實現(xiàn)，這種操作不僅緩慢并且無法隨著這些表中元組數(shù)量的增加而伸縮。

　　屬性圖形（Property Graph）的基本術語

　　在圖的領域，并沒有一套被廣泛接受的術語，存在著很多不同類型的圖模型。但是，有人致力于創(chuàng)建一種屬性圖形模型（Property Graph Model），以期統(tǒng)一大多數(shù)不同的圖實現(xiàn)。按照該模型，屬性圖里信息的建模使用3種構造單元：

• 節(jié)點（即頂點）
• 關系（即邊）-具有方向和類型（標記和標向）
• 節(jié)點和關系上面的屬性（即特性）

　　更特殊的是，這個模型是一個被標記和標向的屬性多重圖（multigraph）。被標記的圖每條邊都有一個標簽，它被用來作為那條邊的類型。有向圖允許邊有一個固定的方向，從末或源節(jié)點到首或目標節(jié)點。屬性圖允許每個節(jié)點和邊有一組可變的屬性列表，其中的屬性是關聯(lián)某個名字的值，簡化了圖形結構。多重圖允許兩個節(jié)點之間存在多條邊。這意味著兩個節(jié)點可以由不同邊連接多次，即使兩條邊有相同的尾、頭和標記。

　　下圖顯示了一個被標記的小型屬性圖。

　　TinkerPop有關的小型人員圖

　　圖論的巨大用途被得到了認可，它跟不同領域的很多問題都有關聯(lián)。最常用的圖論算法包括各種類型的最短路徑計算、測地線（Geodesic Path）、集中度測量（如PageRank、特征向量集中度、親密度、關系度、HITS等）。然而，在很多情況下，這些算法的應用僅限制于研究，因為實際中沒有任何可用于產品環(huán)境下的高性能圖形數(shù)據(jù)庫實現(xiàn)。幸運的是，近些年情況有所改觀。有幾個項目已經被開發(fā)出來，而且目標直指24/7的產品環(huán)境：

• Neo4j -開源的Java屬性圖形模型
• AllegroGraph，閉源，RDF-QuadStore
• Sones -閉源，關注于.NET
• Virtuoso -閉源，關注于RDF
• HyergraphDB -開源的Java超圖模型
• Others like InfoGrid、Filament、FlockDB等。

　　下圖展示了在復雜度和伸縮性方面背景下的主要NOSQL分類的位置。

　　關于“規(guī)模擴展和復雜度擴展的比較”的更多內容，請閱讀Emil Eifrem的博文。

　　Neo4j -基于Java的圖形數(shù)據(jù)庫

　　Neo4j是一個用Java實現(xiàn)、完全兼容ACID的圖形數(shù)據(jù)庫。數(shù)據(jù)以一種針對圖形網絡進行過優(yōu)化的格式保存在磁盤上。Neo4j的內核是一種極快的圖形引擎，具有數(shù)據(jù)庫產品期望的所有特性，如恢復、兩階段提交、符合XA等。自2003年起，Neo4j就已經被作為24/7的產品使用。該項目剛剛發(fā)布了1.0版 -關于伸縮性和社區(qū)測試的一個主要里程碑。通過聯(lián)機備份實現(xiàn)的高可用性和主從復制目前處于測試階段，預計在下一版本中發(fā)布。Neo4j既可作為無需任何管理開銷的內嵌數(shù)據(jù)庫使用；也可以作為單獨的服務器使用，在這種使用場景下，它提供了廣泛使用的REST接口，能夠方便地集成到基于php、.NET和JavaScript的環(huán)境里。但本文的重點主要在于討論Neo4j的直接使用。

開發(fā)者可以通過Java-API直接與圖形模型交互，這個API暴露了非常靈活的數(shù)據(jù)結構。至于象JRuby/Ruby、Scala、Python、Clojure等其他語言，社區(qū)也貢獻了優(yōu)秀的綁定庫。Neo4j的典型數(shù)據(jù)特征：

• 數(shù)據(jù)結構不是必須的，甚至可以完全沒有，這可以簡化模式變更和延遲數(shù)據(jù)遷移。
• 可以方便建模常見的復雜領域數(shù)據(jù)集，如CMS里的訪問控制可被建模成細粒度的訪問控制表，類對象數(shù)據(jù)庫的用例、TripleStores以及其他例子。
• 典型使用的領域如語義網和RDF、LinkedData、GIS、基因分析、社交網絡數(shù)據(jù)建模、深度推薦算法以及其他領域。

　　甚至“傳統(tǒng)”RDBMS應用往往也會包含一些具有挑戰(zhàn)性、非常適合用圖來處理的數(shù)據(jù)集，如文件夾結構、產品配置、產品組裝和分類、媒體元數(shù)據(jù)、金融領域的語義交易和欺詐檢測等。

　　圍繞內核，Neo4j提供了一組可選的組件。其中有支持通過元模型構造圖形結構、SAIL -一種SparQL兼容的RDF TripleStore實現(xiàn)或一組公共圖形算法的實現(xiàn)。

　　要是你想將Neo4j作為單獨的服務器運行，還可以找到REST包裝器。這非常適合使用LAMP軟件搭建的架構。通過memcached、e-tag和基于Apache的緩存和Web層，REST甚至簡化了大規(guī)模讀負荷的伸縮。

　　高性能？

　　要給出確切的性能基準數(shù)據(jù)很難，因為它們跟底層的硬件、使用的數(shù)據(jù)集和其他因素關聯(lián)很大。自適應規(guī)模的Neo4j無需任何額外的工作便可以處理包含數(shù)十億節(jié)點、關系和屬性的圖。它的讀性能可以很輕松地實現(xiàn)每毫秒（大約每秒1-2百萬遍歷步驟）遍歷2000關系，這完全是事務性的，每個線程都有熱緩存。使用最短路徑計算，Neo4j在處理包含數(shù)千個節(jié)點的小型圖時，甚至比MySQL快1000倍，隨著圖規(guī)模的增加，差距也越來越大。

　　這其中的原因在于，在Neo4j里，圖遍歷執(zhí)行的速度是常數(shù)，跟圖的規(guī)模大小無關。不象在RDBMS里常見的聯(lián)結操作那樣，這里不涉及降低性能的集合操作。Neo4j以一種延遲風格遍歷圖-節(jié)點和關系只有在結果迭代器需要訪問它們的時候才會被遍歷并返回，對于大規(guī)模深度遍歷而言，這極大地提高了性能。

　　寫速度跟文件系統(tǒng)的查找時間和硬件有很大關系。Ext3文件系統(tǒng)和SSD磁盤是不錯的組合，這會導致每秒大約100,000寫事務操作。

　　示例-黑客帝國

　　前面已經說過，社交網絡只是代表了圖形數(shù)據(jù)庫應用的冰山一角，但用它們來作為例子可以讓人很容易理解。為了闡述Neo4j的基本功能，下面這個小型圖來自黑客帝國這部電影。該圖是用Neo4j的Neoclipse產生的，該插件基于Eclipse RCP：

　　這個圖鏈接到一個已知的引用節(jié)點（id=0），這是為了方便的從一個已知起點找到條路進入這個網絡。這個節(jié)點不是必須的，但實踐證明它非常有用。

　　Java的實現(xiàn)看上去大概是這個樣子：

　　在“target/neo”目錄創(chuàng)建一個新的圖形數(shù)據(jù)庫

EmbeddedGraphDatabase graphdb = new EmbeddedGraphDatabase("target/neo");        

        

        
        
      
        
it知識庫：圖形數(shù)據(jù)庫、NOSQL和Neo4j，轉載需保留來源！
        
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。