在選擇數(shù)據(jù)庫的路上，我們遇到過哪些坑？（一）

數(shù)據(jù)庫大數(shù)據(jù) 數(shù)據(jù)分析數(shù)據(jù)工具

OneAPM 官方博客 | 2016-08-16 10:40

【數(shù)據(jù)猿導(dǎo)讀】你會怎么選擇數(shù)據(jù)庫，是關(guān)系數(shù)據(jù)庫、XML 數(shù)據(jù)庫、資源描述框架（RDF），還是圖形數(shù)據(jù)庫？這篇演講深入而生動地探討了各種選擇

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

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

選擇數(shù)據(jù)庫

關(guān)系數(shù)據(jù)庫

最初，我們的創(chuàng)始人準(zhǔn)備把數(shù)千份不同的文件放在一起，用來執(zhí)行有效搜索、制定業(yè)務(wù)決策、進(jìn)行數(shù)據(jù)分析和創(chuàng)建數(shù)據(jù)可視化。

我們在研究過程中發(fā)現(xiàn)，關(guān)系數(shù)據(jù)庫 (RDBMS) 并不適合我們。當(dāng)然，我們的本能反應(yīng)就是使用這種數(shù)據(jù)庫，畢竟我們已經(jīng)用了這么長時間。但關(guān)系數(shù)據(jù)庫需要固定的架構(gòu)，并且創(chuàng)建數(shù)據(jù)庫時就要設(shè)置好這一固定架構(gòu)。用戶必須創(chuàng)建各種表，確定關(guān)系，然后創(chuàng)建 JOIN 連接：

XML 數(shù)據(jù)庫而我們需要的是比關(guān)系模型更為靈活的數(shù)據(jù)庫。

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

我們認(rèn)識到，文檔之間的隱含信息比存儲在每個文檔內(nèi)的信息要有意思得多。于是我們試著弄清楚能不能創(chuàng)建一個數(shù)據(jù)庫好讓我們利用這些關(guān)系。我們確實(shí)從這一初始概念點(diǎn)(POC)學(xué)到了一些東西，但顧名思義，概念點(diǎn)本身就是一種不夠全面的看法。我們依次對這一看法的各個子集進(jìn)行測試，然后選取部分樣本集，發(fā)現(xiàn)能夠進(jìn)行快速搜索和導(dǎo)航。

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

我們可以在文檔內(nèi)進(jìn)行快速搜索，但不能對文檔之間的關(guān)系進(jìn)行快速搜索。對于這項(xiàng)操作而言，這一數(shù)據(jù)庫并不合適。

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

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

這不算太難，因?yàn)槲覀兒苄⌒牡貜募軜?gòu)的剩余部分解耦了持久層。最后花了大約兩個月時間，然后我們終于能在不影響應(yīng)用程序剩余部分的情況下進(jìn)行遷移。

我們?yōu)槭裁催x擇資源描述框架?因?yàn)樗菍檫B接帶有統(tǒng)一資源標(biāo)識符的信息而設(shè)計的，還擁有一種叫做 SPARQL 的標(biāo)準(zhǔn)化查詢語言。

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

如果我想說 Clark 認(rèn)識 John Forrest，那么 Clark 就是資源。資源具有名字、姓氏和類型等屬性，也具有關(guān)系。下面這些資源描述框架的三元組可以體現(xiàn)這一示意圖：下面是資源描述框架概念的簡單象形圖：

資源描述框架非常冗長，它是一種基于非屬性的圖形。由于所有內(nèi)容都表現(xiàn)為節(jié)點(diǎn)，要想進(jìn)行復(fù)雜的關(guān)系查詢，必須先到達(dá)目的地然后再一同返回，這給我們帶來了一些性能問題。雖然資源描述框架沒有成為我們的最終選擇，但它確實(shí)幫我們看清了專注于數(shù)據(jù)關(guān)系的希望。我們的數(shù)據(jù)庫確實(shí)很給力，總體來說我們也相當(dāng)滿意。利用資源描述框架，我們不僅重建了整個概念點(diǎn)，還實(shí)現(xiàn)了對數(shù)據(jù)庫的更多操作 —— 包括探索各種關(guān)系。雖然在各個機(jī)構(gòu)和行業(yè)之間進(jìn)行大范圍的數(shù)據(jù)分享時非常方便，但這并不是我們使用數(shù)據(jù)庫的主要目的。

作為一家小型初創(chuàng)公司，在這么短的時間里經(jīng)歷了這么多種數(shù)據(jù)庫，我們有些擔(dān)心。即使這樣，我們?nèi)匀幻靼?，從一開始就要選擇合適的數(shù)據(jù)庫是多么的重要，于是我們頂著重重壓力，在沒有做好充分的數(shù)據(jù)庫工作的情況下，我們決定嘗試圖形數(shù)據(jù)庫。

改變從這里開始：圖形數(shù)據(jù)庫

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

TitanDB 數(shù)據(jù)庫于是我們又明白了，我們不能使用關(guān)系數(shù)據(jù)庫，因?yàn)樗鼈冊陉P(guān)系上的表現(xiàn)不夠出色。JOIN 連接、外鍵和索引既不真實(shí)，也不具體;它們只是我們畫在紙上用來方便理解的圖案。反過來說，在圖形數(shù)據(jù)庫中，關(guān)系被表達(dá)成具體實(shí)體。

我們先研究了 TitanDB，它各項(xiàng)強(qiáng)大的功能和極佳的可擴(kuò)展性一開始讓我們非常振奮?？上У氖?，TitanDB 的啟動和維護(hù)都非常復(fù)雜，必須得從 Cassandra或 HBase 后臺運(yùn)行。

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

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

OrientDB 數(shù)據(jù)庫

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

發(fā)現(xiàn) Neo4j

然后我們發(fā)現(xiàn)了 Neo4j。Neo4j 可高度擴(kuò)展，對節(jié)點(diǎn)、關(guān)系或索引的數(shù)量沒有限制。同時 Neo4j 入門也相當(dāng)簡單，這對我們是很大的誘惑;在使用第三個數(shù)據(jù)庫時，必須得迅速投入運(yùn)行。

性能表現(xiàn)極佳，擴(kuò)增也非常廣泛，并且只專注于圖形用例。Titan 確實(shí)提供映射(作為本地節(jié)點(diǎn)類型)支持，但我們知道，即使沒有這一支持我們也可以繼續(xù)下去。

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