?譯者 | 崔皓

審校 | 孫淑娟

近年來，圖數(shù)據(jù)庫有了大規(guī)模的發(fā)展，它們被應用到很多領域并參與優(yōu)秀的解決方案。它們的靈活性使其更容易以傳統(tǒng)關系型數(shù)據(jù)庫無法做到的方式利用數(shù)據(jù)之間的關系和連接。但是，你真的知道何時使用圖數(shù)據(jù)庫嗎？在這篇文章中，我們探討了在使用圖數(shù)據(jù)庫之前需要考慮什么，甚至在思考之后得出不使用圖數(shù)據(jù)庫的結論。

1、什么是圖形數(shù)據(jù)庫？

圖數(shù)據(jù)庫是一種使用圖理論作為數(shù)據(jù)模型基礎的數(shù)據(jù)庫。圖數(shù)據(jù)庫將連接性視為“一等公民”，使其比傳統(tǒng)的關系型數(shù)據(jù)庫更適合表示數(shù)據(jù)之間的連接。

有兩種類型的圖技術。RDF/語義網(wǎng)和屬性圖。雖然語義網(wǎng)標準已經(jīng)存在了很長時間，但屬性圖已經(jīng)成為主導技術，其中Cypher采用了大量的圖查詢語言。

從本質(zhì)上講，屬性圖數(shù)據(jù)庫中的數(shù)據(jù)模型由以下屬性組成：節(jié)點、邊、屬性和標簽。

• 節(jié)點有屬性。
• 節(jié)點帶有一個或多個標簽。
• 邊是有方向的，連接節(jié)點以創(chuàng)建圖中的結構。
• 邊緣可以有屬性。

圖數(shù)據(jù)庫應用于具有相互連接的數(shù)據(jù)。幾個常見的用例包括：

• 推薦引擎
• 語義搜索
• 反洗錢
• 欺詐檢測
• 360度客戶視圖

除了這些應用之外，對于那些不僅要管理大量數(shù)據(jù)而且需要產(chǎn)生業(yè)務見解的組織來說，圖數(shù)據(jù)庫已經(jīng)成為推薦的解決方案。圖數(shù)據(jù)庫有望成為獲得這種洞察力的最簡單方法，因為它使我們很容易理解數(shù)據(jù)中的關系和背景。

二、圖數(shù)據(jù)庫的挑戰(zhàn)

盡管有這些承諾，圖數(shù)據(jù)庫并沒有征服世界。根據(jù)DB-Engines的數(shù)據(jù)，截至2022年10月，它們僅占數(shù)據(jù)庫份額的1.8%，與實現(xiàn)這些承諾相去甚遠。有幾個原因可以解釋采用圖數(shù)據(jù)庫所遇到的困難。它們可以總結為以下幾點：

1、對高度關聯(lián)的數(shù)據(jù)進行建模

由于圖數(shù)據(jù)庫的高度表達性和相關的復雜性，在圖中建模數(shù)據(jù)并不容易。它類似于知識建模，也被稱為知識工程--一種需要高度專業(yè)化工程師的高級技能。這使得圖很難被普通開發(fā)者采用，設置了很高的進入門檻。

2、保持數(shù)據(jù)的連貫性

圖數(shù)據(jù)庫的另一個大問題是缺乏一個強制的模式。圖形數(shù)據(jù)庫大多將模式驗證委托給應用層，無論是隱式的還是顯式的。這使得創(chuàng)建復雜數(shù)據(jù)的應用變得更加困難，因為數(shù)據(jù)一致性是至關重要的。圖數(shù)據(jù)庫中缺乏明確執(zhí)行的模式，這也是其難以被廣泛應用的主要原因。

3、查詢數(shù)據(jù)

審問圖也遇到了挑戰(zhàn)，由于（隱含的）數(shù)據(jù)模型會制約表達的路徑，因此需要對查詢進行設計，使之與隱含的數(shù)據(jù)模型相匹配。這一點非常具有挑戰(zhàn)性，你需要以最理想的方式對數(shù)據(jù)進行建模。此外，大多數(shù)圖數(shù)據(jù)庫缺乏重要的建模結構，如嵌套或n-ary關系，這導致了建模決策的不一致。有時可能會把關系定義為節(jié)點，有時則定義為邊。這樣一來，查詢可能就不一定能獲取到正確的數(shù)據(jù)。

三、強類型數(shù)據(jù)庫

克服上述挑戰(zhàn)對于幫助實現(xiàn)圖數(shù)據(jù)庫至關重要。這就是為什么要開發(fā)一種新型的數(shù)據(jù)庫：強類型數(shù)據(jù)庫：TypeDB。開源的TypeDB通過提供一個更高級別的類型系統(tǒng)來抽象出圖數(shù)據(jù)庫的低級實現(xiàn)，使開發(fā)者更容易處理復雜的數(shù)據(jù)。TypeDB的類型系統(tǒng)基于以下的核心概念。

1、實體-關系模型

TypeDB使用實體-關系模型進行數(shù)據(jù)建模。與圖數(shù)據(jù)庫不同，這意味著可以將任何ER圖直接映射到TypeQL（TypeDB的查詢語言）中，以避免規(guī)范化的過程。這意味著在概念上認為模型是以人類熟悉的方式來創(chuàng)建的。

TypeDB的模型是由實體類型、關系類型和屬性類型組成，并引入了角色類型。

下面的例子顯示了TypeQL中的基本模型是如何寫的。

define

person sub entity,
owns name,
plays employment:employee;
company sub entity,
owns name,
plays employment:employer;
employment sub relation,
relates employee,
relates employer;
name sub attribute,
  value string;

在這個命名法中，方塊表示實體；鉆石表示關系；橢圓表示屬性。圖中概述了兩個實體的模型——人和公司，兩個實體都擁有名稱屬性。人在雇傭關系中扮演雇員的角色，而公司則扮演雇主的角色。

2、類型層次結構

TypeDB提供了開箱即用的類型層次模型，這是圖數(shù)據(jù)庫不支持的一個特性。遵循面向對象的類型系統(tǒng)的原則，TypeDB確保所有類型繼承他們的超類型的行為和屬性。這使得復雜的數(shù)據(jù)結構可以重復使用，并且通過多態(tài)性使數(shù)據(jù)解釋更加豐富。

在下面的例子中，三層實體人的層次結構被建模。它的所有子類型將繼承屬性的名字和姓氏，而不需要逐一重新聲明這些。

define

person sub entity,
owns first-name,
owns last-name;
student sub person;
undergrad sub student;
postgrad sub student;
teacher sub person;
supervisor sub teacher;
    professor sub teacher;

類型層次描述了由學生和教師類型組成的實體的子類型。有兩種類型的學生，本科生和研究生，有兩種類型的教師，監(jiān)督員和教授。

3、嵌套關系

關系是用來描述兩個或多個事物之間關聯(lián)的。有時事物本身就是關系，這意味著對需要指向另一個關系的關系進行建模--嵌套。圖數(shù)據(jù)庫不允許對嵌套關系進行建模，因為這樣就需要讓一個二元邊指向另一個二元邊。實現(xiàn)這一點的唯一可能方式是通過“reification”（具體化，將關系-邊轉化為點-實體節(jié)點），也就是將一條邊轉化為一個節(jié)點，以便另一條邊可以指向它。

然而，TypeDB支持嵌套關系，使其以最自然的形式進行數(shù)據(jù)建模。在下面的例子中，婚姻類型的關系被分配給變量$mar，然后通過關系將其與一個城市進行關聯(lián)。

match

$alice isa person, has name "Alice";
$bob isa person, has name "Bob";
$mar ($alice, $bob) isa marriage;
$city isa city;
($mar, $city) isa location;

圖中，"Alice "扮演妻子的角色，而 "Bob "扮演丈夫的角色?；橐鍪且粋€嵌套關系，因為它也在位置關系中扮演定位的角色，而城市 "倫敦 "在關系中扮演定位的角色。

4、多元關系

在現(xiàn)實世界中，關系并不只是指事物之間的二元聯(lián)系。我們經(jīng)常需要同時捕捉三個或更多相互關聯(lián)的事物。如果將它們表示二元關系會導致信息損失，這種情況常常會在圖數(shù)據(jù)庫中發(fā)生。另一方面，TypeDB可以很自然地將多個事物表示為一種關系。

在這個例子中，n-ary關系cast連接了三個不同的實體：人的實體，角色的實體和電影的實體。

match

$person isa person, has name "Leonardo";
$character isa character, has name "Jack";
$movie isa movie, has name $movie-name;
(actor: $person, character: $character, movie: $movie) isa cast;
get $movie-name;

這是n-ary關系的例子，具體來說是三元關系，關系類型是cast。關系與三個實體相關：電影 "泰坦尼克號 扮演電影中角色“杰克”的演員是"萊昂納多 "。

5、安全問題

與圖數(shù)據(jù)庫不同，TypeDB提供了一種方法來描述數(shù)據(jù)的邏輯結構，允許TypeDB驗證代碼是否正確插入和數(shù)據(jù)的查詢。查詢驗證超越了靜態(tài)類型檢查，包括對無意義的查詢進行邏輯驗證。通過嚴格的類型檢查錯誤，你將獲得一個可以信任的數(shù)據(jù)集。

下面的插入查詢例子中，Charlie和DataCo之間的關系將被系統(tǒng)拒絕，因為一個人不能和一個公司結婚（假設模式遵循真實世界一般規(guī)律）。

insert

$charlie isa person, has name "Charlie";
$dataCo isa company, has name "DataCo";
(husband: $charlie, wife: $dataCo) isa marriage; # invalid relation

commit>>

ERROR: invalid data detected during type validation

6、推理

最后，TypeDB提供了一個內(nèi)置的推理引擎，這使得TypeDB能夠推導出新見解，并提供對應的解釋。另一方面，屬性圖并不提供原生的推理能力。

TypeDB的推斷是基于模式中的規(guī)則。在查詢運行期間，如果數(shù)據(jù)集中的某個邏輯形式被滿足（如規(guī)則中定義的），系統(tǒng)將得出新的結論。就像編程中的函數(shù)一樣，規(guī)則可以相互連鎖，在數(shù)據(jù)層面創(chuàng)建行為的抽象。

通過下面的規(guī)則，TypeDB將能夠推斷出一個城市位于一個大陸，盡管兩者之間不存在明確的關系。

define

rule transitive-location:
when {
(located: $city, locating: $country) isa location;
(located: $country, locating: $continent) isa location;
} then {
(located: $city, locating: $continent) isa location;
};

使用自動推理，TypeDB可以推斷出 "卡姆登 "區(qū)和 "英國 "之間的關系（虛線），盡管它們沒有直接聯(lián)系。

四、總結

回到我們的主題，什么時候使用圖數(shù)據(jù)庫呢？圖是為那些依賴復雜和相互連接的數(shù)據(jù)應用而準備。正如我們所看到的，他們?nèi)狈V泛的應用，這也是圖數(shù)據(jù)庫失敗的原因和面臨的挑戰(zhàn)。為了面對挑戰(zhàn)并實現(xiàn)圖形數(shù)據(jù)庫的最初承諾，我們建立了TypeDB。

原文鏈接：https://dzone.com/articles/when-not-to-use-a-graph-database

譯者介紹

崔皓，51CTO社區(qū)編輯，資深架構師，擁有18年的軟件開發(fā)和架構經(jīng)驗，10年分布式架構經(jīng)驗。?