在選擇數據庫的路上，咱們遇到過哪些坑？（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