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

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

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

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

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

選擇數據庫

關系數據庫

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

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

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

XML 數據庫

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

改變從這里開始：圖形數據庫

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

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

TitanDB 數據庫

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

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

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

OrientDB 數據庫

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

發現 Neo4j

然后我們發現了 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

總結

以上是生活随笔為你收集整理的在选择数据库的路上，我们遇到过哪些坑？（1）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。