摘要：資源描述框架三元組存儲(chǔ)為了解決問(wèn)題，把我們的所有文檔從遷移到資源描述框架，這一框架又被稱(chēng)為三元組存儲(chǔ)。下面這些資源描述框架的三元組可以體現(xiàn)這一示意圖我們的數(shù)據(jù)庫(kù)確實(shí)很給力，總體來(lái)說(shuō)我們也相當(dāng)滿(mǎn)意。

【編者按】你會(huì)怎么選擇數(shù)據(jù)庫(kù)，是關(guān)系數(shù)據(jù)庫(kù)、XML 數(shù)據(jù)庫(kù)、資源描述框架（RDF），還是圖形數(shù)據(jù)庫(kù)？這篇演講深入而生動(dòng)地探討了各種選擇。本文系國(guó)內(nèi) ITOM 管理平臺(tái) OneAPM 編譯呈現(xiàn)。

備注：在去年十月于舊金山舉辦的 GraphConnect 大會(huì)上，F(xiàn)actGem 公司首席技術(shù)官 Clark Richey發(fā)表了這篇演講，解釋了他決定選擇 Neo4j 數(shù)據(jù)的原因。

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

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

2014 年夏天之后，很多事情都發(fā)生了變化，我也會(huì)對(duì)我們?cè)谶@段時(shí)期測(cè)試的各種數(shù)據(jù)庫(kù)做出一個(gè)仔細(xì)的評(píng)估。

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

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

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

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

我們確實(shí)從這一初始概念點(diǎn)(POC)學(xué)到了一些東西，但顧名思義，概念點(diǎn)本身就是一種不夠全面的看法。我們依次對(duì)這一看法的各個(gè)子集進(jìn)行測(cè)試，然后選取部分樣本集，發(fā)現(xiàn)能夠進(jìn)行快速搜索和導(dǎo)航。

我們認(rèn)識(shí)到，文檔之間的隱含信息比存儲(chǔ)在每個(gè)文檔內(nèi)的信息要有意思得多。于是我們?cè)囍宄懿荒軇?chuàng)建一個(gè)數(shù)據(jù)庫(kù)好讓我們利用這些關(guān)系。

我們?cè)俅螌⑿畔⒔＃纬晌臋n，后者非常適合我們的數(shù)據(jù)集。但使用文檔數(shù)據(jù)庫(kù)時(shí)，用戶(hù)真正關(guān)心的當(dāng)然是文檔了。因此，盡管我們可以進(jìn)行 JOIN 連接，但仍然不適用于大型數(shù)據(jù)集。

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

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

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

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

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

下面是資源描述框架概念的簡(jiǎn)單象形圖：

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

我們的數(shù)據(jù)庫(kù)確實(shí)很給力，總體來(lái)說(shuō)我們也相當(dāng)滿(mǎn)意。利用資源描述框架，我們不僅重建了整個(gè)概念點(diǎn)，還實(shí)現(xiàn)了對(duì)數(shù)據(jù)庫(kù)的更多操作 —— 包括探索各種關(guān)系。雖然在各個(gè)機(jī)構(gòu)和行業(yè)之間進(jìn)行大范圍的數(shù)據(jù)分享時(shí)非常方便，但這并不是我們使用數(shù)據(jù)庫(kù)的主要目的。

資源描述框架非常冗長(zhǎng)，它是一種基于非屬性的圖形。由于所有內(nèi)容都表現(xiàn)為節(jié)點(diǎn)，要想進(jìn)行復(fù)雜的關(guān)系查詢(xún)，必須先到達(dá)目的地然后再一同返回，這給我們帶來(lái)了一些性能問(wèn)題。雖然資源描述框架沒(méi)有成為我們的最終選擇，但它確實(shí)幫我們看清了專(zhuān)注于數(shù)據(jù)關(guān)系的希望。

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

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

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

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

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

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

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

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

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

總的來(lái)說(shuō)，我們之所以選擇 Neo4j，有以下原因：

我們使用 Neo4j 企業(yè)版已有大約 16 個(gè)月，體驗(yàn)一直非常美好。Neo4j 易于使用，設(shè)置和維護(hù)也很簡(jiǎn)單，實(shí)現(xiàn)甚至超出了我們的預(yù)期。它讓我們超越了我們的概念點(diǎn)，非常非常迅速地投入運(yùn)行和構(gòu)建新事物。

在本文的第二部分，將詳細(xì)介紹使用 Neo4j 之后，作者學(xué)習(xí)到的經(jīng)驗(yàn)教訓(xùn)，敬請(qǐng)期待。

本文系 OneAPM 工程師整理呈現(xiàn)。OneAPM 能為您提供端到端的應(yīng)用性能解決方案，我們支持所有常見(jiàn)的框架及應(yīng)用服務(wù)器，助您快速發(fā)現(xiàn)系統(tǒng)瓶頸，定位異常根本原因。分鐘級(jí)部署，即刻體驗(yàn)，性能監(jiān)控從來(lái)沒(méi)有如此簡(jiǎn)單。想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問(wèn) OneAPM 官方技術(shù)博客。

本文轉(zhuǎn)自 OneAPM 官方博客

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