目錄

一、關係型資料庫(Relational Database)

當我們準備把數千份不同的檔案放在一起，用來執行有效搜尋、制定業務決策、進行資料分析和建立資料視覺化的時候，肯定會用到資料庫。

在眾多不同的資料模型裡，關係資料模型自20世紀80年代就處於統治地位，而且出現了不少巨頭，如Oracle、MySQL，它們也被稱為：關係資料庫管理系統（RDBMS）。

然而，隨著關係資料庫使用範圍的不斷擴大，也暴露出一些它始終無法解決問題，其中最主要的是資料建模中的一些缺陷和問題，以及在大資料量和多伺服器之上進行水平伸縮的限制。同時，網際網路發展也產生了一些新的趨勢變化： 使用者、系統和感測器產生的資料量呈指數增長，資料量不斷增加，大資料的儲存和處理；

新時代網際網路形勢下的問題急迫性，這一問題因網際網路+、社交網路，智慧推薦等的大規模興起和繁榮而變得越加緊迫。

在研究過程中發現，關係資料庫 (RDB) 並不適合我們。當然，我們的本能反應就是使用這種資料庫，畢竟我們已經用了這麼長時間。但關係資料庫需要固定的架構，並且建立資料庫時就要設定好這一固定架構。使用者必須建立各種表，確定關係，然後建立 JOIN 連線。此時，我們需要的是比關係模型更為靈活的資料庫。

二、非關係型資料庫（NoSQL）

而在應對這些趨勢時，關係資料庫產生了更多的不適應性，從而導致大量解決這些問題中某些特定方面的不同技術出現，它們可以與現有RDBMS相互配合或代替它們。過去的幾年間，出現了大量新型資料庫，它們被統稱為非關係型資料庫(NoSQL)

NoSQL 是一類範圍非常廣泛的持久化解決方案，它們不遵循關係資料庫模型，也不使用SQL作為查詢語言。其資料儲存可以不需要固定的表格模式，也經常會避免使用SQL的JOIN操作，一般有水平可擴充套件的特徵。

簡言之，NoSQL資料庫可以按照它們的資料模型分成4類：

• 鍵-值儲存庫（Key-Value-stores）;
• BigTable實現（BigTable-implementations）;
• 文件庫（Document-stores）;
• 圖形資料庫（Graph Database）;

三、XML 資料庫

我曾經接觸過 NoSQL 資料庫。那時我在 MarkLogic 公司工作。MarkLogic 是一家企業級模式自由型 XML 資料庫公司，該公司還儲存文件並提供 JSON 格式。這種資料庫無論在上傳資訊還是執行搜尋時，速度都較快，並且模式自由。

我們確實從這一初始概念點(POC)學到了一些東西，但顧名思義，概念點本身就是一種不夠全面的看法。我們依次對這一看法的各個子集進行測試，然後選取部分樣本集，發現能夠進行快速搜尋和導航。我們認識到，文件之間的隱含資訊比儲存在每個文件內的資訊要有意思得多。於是我們試著弄清楚能不能建立一個數據庫好讓我們利用這些關係。我們再次將資訊建模，形成文件，後者非常適合我們的資料集。但使用文件資料庫時，使用者真正關心的當然是文件了。因此，儘管我們可以進行 JOIN 連線，但仍然不適用於大型資料集。我們可以在文件內進行快速搜尋，但不能對文件之間的關係進行快速搜尋。對於這項操作而言，這一資料庫並不合適。

四、資源描述框架 (RDF) / 三元組儲存

為了解決問題，MarkLogic 把我們的所有文件從 XML 遷移到資源描述框架 (RDF)，這一框架又被稱為三元組儲存。這無疑是個大手筆，也是非常與眾不同的對待資料的方式，我們決定，就是它了。

這不算太難，因為我們很小心地從架構的剩餘部分解耦了持久層。最後花了大約兩個月時間，然後我們終於能在不影響應用程式剩餘部分的情況下進行遷移。我們為什麼選擇資源描述框架？因為它是專為連線帶有統一資源識別符號的資訊而設計的，還擁有一種叫做 SPARQL 的標準化查詢語言。

簡而言之，資源描述框架是有關主/謂/賓關係的，從下面看得出來，其模型非常簡單：

下面是資源描述框架概念的簡單象形圖：

如果我想說 Clark 認識 John Forrest，那麼 Clark 就是資源。資源具有名字、姓氏和型別等屬性，也具有關係。下面這些資源描述框架的三元組可以體現這一示意圖：

我們的資料庫確實很給力，總體來說我們也相當滿意。利用資源描述框架，我們不僅重建了整個概念點，還實現了對資料庫的更多操作 —— 包括探索各種關係。雖然在各個機構和行業之間進行大範圍的資料分享時非常方便，但這並不是我們使用資料庫的主要目的。

資源描述框架非常冗長，它是一種基於非屬性的圖形。由於所有內容都表現為節點，要想進行復雜的關係查詢，必須先到達目的地然後再一同返回，這給我們帶來了一些效能問題。雖然資源描述框架沒有成為我們的最終選擇，但它確實幫我們看清了專注於資料關係的希望。

作為一家小型初創公司，在這麼短的時間裡經歷了這麼多種資料庫，我們有些擔心。即使這樣，我們仍然明白，從一開始就要選擇合適的資料庫是多麼的重要，於是我們頂著重重壓力，在沒有做好充分的資料庫工作的情況下，我們決定嘗試圖形資料庫。

五、圖形資料庫（Graph Database）

定義：圖形資料庫是NoSQL資料庫的一種型別，它應用圖形理論儲存實體之間的關係資訊。圖形資料庫是一種非關係型資料庫，它應用圖形理論儲存實體之間的關係資訊。最常見例子就是社會網路中人與人之間的關係。關係型資料庫用於儲存“關係型”資料的效果並不好，其查詢複雜、緩慢、超出預期，而圖形資料庫的獨特設計恰恰彌補了這個缺陷。

我們不能使用關係資料庫，因為它們在關係上的表現不夠出色。JOIN 連線、外來鍵和索引既不真實，也不具體；它們只是我們畫在紙上用來方便理解的圖案。反過來說，在圖形資料庫中，關係被表達成具體實體。

5.1 TitanDB 資料庫

我們先研究了 TitanDB，它各項強大的功能和極佳的可擴充套件性一開始讓我們非常振奮。可惜的是，TitanDB 的啟動和維護都非常複雜，必須得從 Cassandra 或 HBase 後臺執行。

我們關心的另一個功能是最終一致儲存，它並不符合 ACID 原理。這表示，如果我們要長時間執行大型圖形資料庫，最後可能會出現不一致現象。

TitanDB 確實提供了一個基本可長期執行的流程，能夠始終如一地穿行整個圖形，以期探測和修復不一致問題。除了這些不一致之外，TitanDB 還可以作為不基於圖形的本地儲存之上的層。

5.2 OrientDB 資料庫

接下來我們又瞭解了 OrientDB。OrientDB 啟動起來似乎簡單得多，還具備大量針對文件的功能。但從社群的評論來看，效能和可擴充套件性是個問題。另外，OrientDB 把自己宣傳成多模式資料庫 ——圖形和 SQL。這種宣傳缺乏對純圖形操作的針對性，讓我很是憂心，我們不僅想要做圖形，還要做好圖形。

5.3 Neo4j 資料庫

然後我們發現了 Neo4j。Neo4j 可高度擴充套件，對節點、關係或索引的數量沒有限制。同時 Neo4j 入門也相當簡單，這對我們是很大的誘惑；在使用第三個資料庫時，必須得迅速投入執行。

效能表現極佳，擴增也非常廣泛，並且只專注於圖形用例。Titan 確實提供對映（作為本地節點型別）支援，但我們知道，即使沒有這一支援我們也可以繼續下去。

總的來說，我們之所以選擇 Neo4j，有以下原因：

在面對社交型關係儲存的時候，資料之間的關係會變得十分複雜。舉個例子，新浪微博一個大V少則十幾萬，多則幾千萬的粉絲，這些關注關係要怎麼存呢？在MySql中，一條關注關係（大V id，大V的一個粉絲 id）存為一條資料，那麼當用戶數量上來的時候，關注關係輕鬆破億，破十億，甚至上百億，並且為了保證每條資料的唯一性，還需要設定聯合索引，MySql就有些力不從心了。那麼有人要說了：分表呀。嗯，沒錯，分表的確可以在插入端和讀取端提升一些速度。比如我們可以根據id雜湊到100張表中。查詢一個使用者有哪些粉絲是快了，但是查詢一個使用者關注了哪些人時仍然需要遍歷全表。好，這時候我們還可以以（id，其關注的一個使用者的id）再構造100張表，於是兩種查詢都快了。然而，後面那100張表是冗餘資料，並且生成一張子圖也不方便（需要多次寫SQL查表）。

於是，在搜尋更好的方案時，發現了圖形資料庫是個不錯的選擇，畢竟業界已經有很多應用了，如twitter，Adobe等。

先簡要介紹一下Neo4j。Neo4j是由Java和Scala寫成的一個NoSql資料庫，專門用於網路圖的儲存。更詳細的內容可見官網。作為一個圖形資料庫，Neo4j有以下優點：

• 更快的資料庫操作。當然，有一個前提條件，那就是資料量較大，在MySql中儲存的話需要許多表，並且表之間聯絡較多（即有不少的操作需要join表）。
• 資料更直觀，相應的SQL語句也更好寫（Neo4j使用Cypher語言，與傳統SQL有很大不同）。
• 更靈活。不管有什麼新的資料需要儲存，都是一律的節點和邊，只需要考慮節點屬性和邊屬性。而MySql中即意味著新的表，還要考慮和其他表的關係。
• 資料庫操作的速度並不會隨著資料庫的增大有明顯的降低。這得益於Neo4j特殊的資料儲存結構和專門優化的圖演算法。

兩大明顯的優勢：

1、資料儲存 Neo4j對於圖的儲存自然是經過特別優化的。不像傳統資料庫的一條記錄一條資料的儲存方式，Neo4j的儲存方式是：節點的類別，屬性，邊的類別，屬性等都是分開儲存的，這將大大有助於提高圖形資料庫的效能。

2、資料讀寫 在Neo4j中，儲存節點時使用了"index-free adjacency"，即每個節點都有指向其鄰居節點的指標，可以讓我們在O(1)的時間內找到鄰居節點。另外，按照官方的說法，在Neo4j中邊是最重要的,是"first-class entities"，所以單獨儲存，這有利於在圖遍歷的時候提高速度，也可以很方便地以任何方向進行遍歷。

未完待續。。。

【參考文獻】