?譯者 | 崔皓

審校 | 孫淑娟

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

1、什么是圖形數據庫？

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

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

從本質上講，屬性圖數據庫中的數據模型由以下屬性組成：節點、邊、屬性和標簽。

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

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

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

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

二、圖數據庫的挑戰

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

1、對高度關聯的數據進行建模

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

2、保持數據的連貫性

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

3、查詢數據

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

三、強類型數據庫

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

1、實體-關系模型

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

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

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

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;

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

3、嵌套關系

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

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

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、多元關系

在現實世界中，關系并不只是指事物之間的二元聯系。我們經常需要同時捕捉三個或更多相互關聯的事物。如果將它們表示二元關系會導致信息損失，這種情況常常會在圖數據庫中發生。另一方面，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、安全問題

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

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

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提供了一個內置的推理引擎，這使得TypeDB能夠推導出新見解，并提供對應的解釋。另一方面，屬性圖并不提供原生的推理能力。

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

通過下面的規則，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可以推斷出 "卡姆登 "區和 "英國 "之間的關系（虛線），盡管它們沒有直接聯系。

四、總結

回到我們的主題，什么時候使用圖數據庫呢？圖是為那些依賴復雜和相互連接的數據應用而準備。正如我們所看到的，他們缺乏廣泛的應用，這也是圖數據庫失敗的原因和面臨的挑戰。為了面對挑戰并實現圖形數據庫的最初承諾，我們建立了TypeDB。

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

譯者介紹

崔皓，51CTO社區編輯，資深架構師，擁有18年的軟件開發和架構經驗，10年分布式架構經驗。?