在選擇資料庫的路上，我們遇到過哪些坑？（1）

【編者按】你會怎麼選擇資料庫，是關聯式資料庫、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