摘要：資源描述框架三元組存儲為了解決問題，把我們的所有文檔從遷移到資源描述框架，這一框架又被稱為三元組存儲。下面這些資源描述框架的三元組可以體現這一示意圖我們的數據庫確實很給力，總體來說我們也相當滿意。

【編者按】你會怎么選擇數據庫，是關系數據庫、XML 數據庫、資源描述框架（RDF），還是圖形數據庫？這篇演講深入而生動地探討了各種選擇。本文系國內 ITOM 管理平臺 OneAPM 編譯呈現。

備注：在去年十月于舊金山舉辦的 GraphConnect 大會上，FactGem 公司首席技術官 Clark Richey發表了這篇演講，解釋了他決定選擇 Neo4j 數據的原因。

我是 FactGem 的首席技術官 Clark Richey。FactGem 是一家小公司。

在這里我想說一說我們是怎么開始接觸數據庫技術的，然后我們做出了哪些改變，我們還需要做出哪些決定，哪些東西影響了我們的決策流程。我還會介紹我們調查研究過的各種數據庫和技術，以及我們在使用 Neo4j 過程中發現的一些最佳做法和最差做法。

2014 年夏天之后，很多事情都發生了變化，我也會對我們在這段時期測試的各種數據庫做出一個仔細的評估。

最初，我們的創始人準備把數千份不同的文件放在一起，用來執行有效搜索、制定業務決策、進行數據分析和創建數據可視化。

我們在研究過程中發現，關系數據庫 (RDBMS) 并不適合我們。當然，我們的本能反應就是使用這種數據庫，畢竟我們已經用了這么長時間。但關系數據庫需要固定的架構，并且創建數據庫時就要設置好這一固定架構。用戶必須創建各種表，確定關系，然后創建 JOIN 連接：

而我們需要的是比關系模型更為靈活的數據庫。

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

我們確實從這一初始概念點(POC)學到了一些東西，但顧名思義，概念點本身就是一種不夠全面的看法。我們依次對這一看法的各個子集進行測試，然后選取部分樣本集，發現能夠進行快速搜索和導航。

我們認識到，文檔之間的隱含信息比存儲在每個文檔內的信息要有意思得多。于是我們試著弄清楚能不能創建一個數據庫好讓我們利用這些關系。

我們再次將信息建模，形成文檔，后者非常適合我們的數據集。但使用文檔數據庫時，用戶真正關心的當然是文檔了。因此，盡管我們可以進行 JOIN 連接，但仍然不適用于大型數據集。

我們可以在文檔內進行快速搜索，但不能對文檔之間的關系進行快速搜索。對于這項操作而言，這一數據庫并不合適。

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

這不算太難，因為我們很小心地從架構的剩余部分解耦了持久層。最后花了大約兩個月時間，然后我們終于能在不影響應用程序剩余部分的情況下進行遷移。

我們為什么選擇資源描述框架？因為它是專為連接帶有統一資源標識符的信息而設計的，還擁有一種叫做 SPARQL 的標準化查詢語言。

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

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

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

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

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

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

最初我們認為圖形數據庫和資源描述框架一個樣。但我們知道，要描述兩個人之間的關系，用資源描述框架太復雜了。我們希望能有一個非常非常簡單的工具，讓我們能夠給節點分配屬性，然后我們在一個屬性圖形模型里找到了以下內容：

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

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

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

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

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

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

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

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

我們使用 Neo4j 企業版已有大約 16 個月，體驗一直非常美好。Neo4j 易于使用，設置和維護也很簡單，實現甚至超出了我們的預期。它讓我們超越了我們的概念點，非常非常迅速地投入運行和構建新事物。

在本文的第二部分，將詳細介紹使用 Neo4j 之后，作者學習到的經驗教訓，敬請期待。

本文系 OneAPM 工程師整理呈現。OneAPM 能為您提供端到端的應用性能解決方案，我們支持所有常見的框架及應用服務器，助您快速發現系統瓶頸，定位異常根本原因。分鐘級部署，即刻體驗，性能監控從來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客

原文地址：https://dzone.com/articles/from-good-to-graph-choosing-the-right-database