1 何需數(shù)據(jù)庫？

互聯(lián)網(wǎng)和移動互聯(lián)網(wǎng)絡的快速發(fā)展帶來了數(shù)據(jù)產(chǎn)生速率的極大增長，每時每刻都有數(shù)以十億量級的設(shè)備在生產(chǎn)出巨大體量的數(shù)據(jù)。

從數(shù)據(jù)產(chǎn)生的渠道來看，主要分為兩類，一類是人類活動生成的數(shù)據(jù)，諸如我們?nèi)粘５木W(wǎng)頁瀏覽、收集等移動設(shè)備的使用；另一類是機器產(chǎn)生的數(shù)據(jù)，如生產(chǎn)線設(shè)備、物聯(lián)網(wǎng)設(shè)備、傳感器、無線網(wǎng)絡等。

從數(shù)據(jù)生成的速度來看，據(jù)國際數(shù)據(jù)公司IDC的監(jiān)測數(shù)據(jù)顯示，2013年，全球大數(shù)據(jù)庫儲量為4.3ZB（相當于47.24億個1TB容量的移動硬盤）；2014年是6.6ZB；2015年是8.6ZB；2018年是33.0ZB……預計在 2030 年，將會有超過千億量級的聯(lián)網(wǎng)傳感設(shè)備產(chǎn)生出巨大體量的數(shù)據(jù)。

圖1：2016年至2020年全球每年產(chǎn)生的數(shù)據(jù)量（單位：ZB，%）

面對每天產(chǎn)生的海量數(shù)據(jù)，人們怎么能夠做到又快又好地找到并調(diào)用呢？于是，數(shù)據(jù)庫就是被創(chuàng)造出來幫助人們快速提取數(shù)據(jù)價值的利器。當然，還有其它類似的概念和工具，諸如數(shù)據(jù)倉庫、數(shù)據(jù)集市、數(shù)據(jù)湖泊等，旨在解決我們?nèi)粘Ｋ鎸Φ臄?shù)據(jù)存儲、數(shù)據(jù)轉(zhuǎn)換、數(shù)據(jù)分析、BI商務智能等一系列工作。

2 數(shù)據(jù)庫的進化路徑

現(xiàn)代商業(yè)社會對數(shù)據(jù)庫性能方面的要求推動了數(shù)據(jù)處理基礎(chǔ)架構(gòu)與技術(shù)的發(fā)展。下圖展示了以數(shù)據(jù)庫為中心的數(shù)據(jù)處理基礎(chǔ)架構(gòu)和技術(shù)的進化路徑：從關(guān)系型數(shù)據(jù)到大數(shù)據(jù)，從大數(shù)據(jù)到快數(shù)據(jù)，從快數(shù)據(jù)到深數(shù)據(jù) ，從深數(shù)據(jù)到圖數(shù)據(jù)。?

1980-2010年間的關(guān)系型數(shù)據(jù)庫主導的階段;

2010-2020年間的大數(shù)據(jù)（NoSQL、數(shù)倉、數(shù)湖、大數(shù)據(jù)框架）主導的大數(shù)據(jù)時代;

2020-2030年則可以預見的是圖計算（圖數(shù)據(jù)庫）的時代。

 圖2：數(shù)據(jù)處理基礎(chǔ)架構(gòu)與技術(shù)的進化路線

數(shù)據(jù)庫的進化是由商業(yè)需求所驅(qū)動的，當企業(yè)IT信息化已經(jīng)基本完成后，再向前就是數(shù)字化轉(zhuǎn)型與全面智能化（數(shù)智化）。

但是，SQL/RDBMS已經(jīng)是有40年歷史的老舊的技術(shù)框架了，即便是變身為數(shù)倉、數(shù)湖、NoSQL、NewSQL還是流批一體化框架，本質(zhì)上依然是在用二維表的模式在對真實世界的業(yè)務場景進行數(shù)據(jù)建模，依然會在處理海量、動態(tài)數(shù)據(jù)、復雜、深度查詢時出現(xiàn)嚴重的性能問題，依然會受到SQL關(guān)系型建模與查詢僵化與淺層缺陷的限制。

我們認為智能化時代的核心技術(shù)一定是可以進行高維數(shù)據(jù)建模，處理高維數(shù)據(jù)關(guān)聯(lián)關(guān)系的圖數(shù)據(jù)庫（圖計算與存儲引擎），而低維的SQL類型的數(shù)據(jù)庫注定會逐步消亡。

這一結(jié)論從數(shù)據(jù)庫的全球國際標準只有SQL（結(jié)構(gòu)化查詢語言）與GQL（圖查詢語言）兩大標準即可看出，前者自1983年至今已經(jīng)歷經(jīng)40年滄桑，而后者將會在2023年推出首個國際版標準。

舉個具體的例子，在銀行業(yè)中的各種指標計算與歸因分析，會涉及全行明細級數(shù)據(jù)、分行、條線、客群、客戶經(jīng)理、集團、供應鏈、指標子項、客戶賬戶信息等多個維度的綜合計算。

用 SQL 和關(guān)系型數(shù)據(jù)庫來計算的復雜度是個天文數(shù)字（多表關(guān)聯(lián)會導致“笛卡爾積”現(xiàn)象，計算復雜度指數(shù)級增加，進而時耗巨大，導致無法在有限資源與時間內(nèi)完成計算）；而用圖計算來建模和實現(xiàn)，是加和而非乘積的關(guān)系，計算復雜度指數(shù)級降低——與RDBMS相比有著指數(shù)級的性能優(yōu)勢。

換言之，用 SQL 來實現(xiàn)，會耗費大量的計算、存儲資源，并且效率非常低下，任何復雜一點的指標計量或歸因分析都無法完成，但用圖計算來實現(xiàn)，可以做到實時，并且耗費較少的硬件資源——更低的 TCO，更高的 ROI，這也是圖數(shù)據(jù)庫的顛覆性優(yōu)勢之一——高性能、高性價比（以及靈活性與白盒化）。

圖3：關(guān)系型數(shù)據(jù)庫（數(shù)倉、數(shù)湖） 中多表連接導致的笛卡爾積問題

知名信息咨詢公司Gartner在2019-2021年間關(guān)于數(shù)據(jù)與分析科技（Data & Analytics Technology Trends）的幾份報告中，明確地提出了圖分析（Graph Analytics）作為十大核心科技發(fā)展趨勢之一，且其所代表的細分市場會以年復合增長率100%的速度持續(xù)增長，預計到2025年，80%的商務智能、商業(yè)決策（BI）的創(chuàng)新會通過圖分析與計算（即圖數(shù)據(jù)庫系統(tǒng)）來實現(xiàn)。

圖4：Garther報告

3 進入”圖“時代

很多我們熟知的科技公司，諸如臉書（Facebook）、Google、推特（Twitter）、領(lǐng)英（Linkedln）等國際巨頭科技公司，其起家的秘密正是源于圖技術(shù)，還有一些金融服務公司，例如高盛（Goldman Sachs）、美國銀行（Bank of America）、BlackRock（黑石）、貝寶（Paypal）等的核心技術(shù)產(chǎn)品正是構(gòu)建在圖計算與圖數(shù)據(jù)庫框架之上。

究其根本是因為圖的核心競爭力更有利于助力企業(yè)進行數(shù)組資產(chǎn)管理、數(shù)據(jù)治理、數(shù)據(jù)分析，并實現(xiàn)真正意義的數(shù)據(jù)智能——圖技術(shù)能以更高效、深度、準確、白盒化的方式揭示出數(shù)據(jù)的內(nèi)部關(guān)聯(lián)。

圖數(shù)據(jù)庫在傳統(tǒng)意義上被歸類為NoSQL數(shù)據(jù)庫的一種（盡管這并不準確，如果從數(shù)據(jù)庫標準的維度看，過去40年數(shù)據(jù)的發(fā)展只有2套標準，一套是SQL，另一套是GQL，即圖查詢語言，僅此一條就可以佐證圖數(shù)據(jù)庫會成為未來的主流數(shù)據(jù)庫，而SQL終將消亡。圖數(shù)據(jù)庫終將獨立成團，這是后話。）

其它的非關(guān)系型數(shù)據(jù)庫在廣義上還包含例如列數(shù)據(jù)庫、寬表數(shù)據(jù)庫、鍵值庫（因其架構(gòu)與接口簡單，嚴格意義上并不算完整的數(shù)據(jù)庫）、文檔數(shù)據(jù)庫、時序數(shù)據(jù)庫等。NoSQL 數(shù)據(jù)庫一般而言被分為以下幾大類，每一類都有其各自的特性：

? 鍵值（Key-Value） : 性能和簡易性

? 寬列（Wide-Column）：體量

? 文檔（Document）：數(shù)據(jù)多樣性

? 時序（Time Series）：IOT 數(shù)據(jù)、時序優(yōu)先性能

? 圖（Graph） : 高維建模+深數(shù)據(jù)+快數(shù)據(jù)

圖5：NOSQL類數(shù)據(jù)庫存儲結(jié)構(gòu)的進化

在眾多 NoSQL 類數(shù)據(jù)庫中，最好的用來詮釋數(shù)據(jù)建模靈活性——無模式（Schema-Free 或 Demi-Schema）的例子就是圖數(shù)據(jù)庫——除了點和邊這兩種基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)以外，圖數(shù)據(jù)庫不需要任何預先定義的模式或表結(jié)構(gòu)。

這種極度簡化的理念恰恰和人類如何思考以及存儲信息有著很大的相似性——人們通常并不在腦海中設(shè)定二維的、僵化的表結(jié)構(gòu)， 因為人腦是可以通過對實體與關(guān)系構(gòu)建的高維、動態(tài)的數(shù)據(jù)模型中“隨機應變”（觸類旁通、舉一反三、關(guān)聯(lián)、發(fā)散、聚合、下鉆）的。

 圖6：關(guān)系網(wǎng)絡圖譜（局部）

上圖展示的是一個典型的關(guān)系圖譜（網(wǎng)絡圖），其是在一張大圖上進行實時路徑查詢時所動態(tài)生成的一張子圖。綠色的節(jié)點為初始頂點，紫色的節(jié)點為終止頂點，兩者間有15層（跳）間隔，并有上100條關(guān)聯(lián)路徑，每條路徑上有不同類型的邊連接著相鄰的兩兩的頂點，其中不同類型（屬性）的邊以不同的色彩來渲染，以表達不同類型的關(guān)聯(lián)關(guān)系。

最近 10 幾年以來，全球 IT 市場上涌現(xiàn)出了 10 幾家圖數(shù)據(jù)庫服務商，從傳統(tǒng)的、非常學術(shù)化的 RDF（資源定義框架）模式圖， 到基于原生圖理念構(gòu)建的LPG（標簽屬性圖） 或 PG（屬性圖） 圖數(shù)據(jù)庫，還有那些在傳統(tǒng) SQL 數(shù)據(jù)庫上或 NoSQL 數(shù)據(jù)庫上搭建的各種非原生圖。

目前業(yè)界圖數(shù)據(jù)庫的架構(gòu)分為三類：

• 第一類是基于傳統(tǒng)關(guān)系型數(shù)據(jù)庫的圖計算，代表產(chǎn)品諸如 Cosmos DB、Oracle PGX等；
• 第二類是基于 Hadoop/Spark 或 NoSQL 存儲引擎的圖數(shù)據(jù)庫， 代表產(chǎn)品諸如星環(huán)、創(chuàng)鄰、JanusGraph、Nebula等；
• 第三類則是原生圖數(shù)據(jù)庫流派，例如Neo4j、TigerGraph、Ultipa，它們區(qū)別于前兩類的地方在于計算與存儲的原生性（Native Graph）。

從嚴格意義的圖數(shù)據(jù)庫產(chǎn)品性能進化的角度來看，作為前沿科技的圖計算、圖數(shù)據(jù)庫技術(shù)在近十年亦歷經(jīng)了四代演進：

• 第一代是諸如基于非原生圖架構(gòu)的JanusGraph（其存儲引擎基于第三方NoSQL構(gòu)建，性能瓶頸明顯，時效性差）；
• 第二代的代表玩家是最早的原生圖數(shù)據(jù)庫Neo4j（缺點在于基于Java架構(gòu)，性能瓶頸明顯，難以在大規(guī)模、復雜、實時性場景中得到推廣）；
• 第三代是并行圖數(shù)據(jù)庫TigerGraph（主要挑戰(zhàn)在于使用門檻高，面向數(shù)據(jù)科學家，二次開發(fā)困難，且基于“單邊圖”理念構(gòu)建，圖建模不靈活）；
• 最新一代就是第四代圖數(shù)據(jù)庫，代表玩家如Ultipa Graph——具備高密度并發(fā)、 融合HTAP+MPP架構(gòu)、建模靈活的實時圖數(shù)據(jù)庫了。

?

圖7：圖數(shù)據(jù)庫的優(yōu)勢、架構(gòu)類型以及產(chǎn)品進化

圖數(shù)據(jù)庫的發(fā)展要解決的并不是數(shù)倉、湖倉系統(tǒng)所鼓吹的無限的數(shù)據(jù)存儲，而是要解決復雜查詢、深度查詢的計算時效性的問題！

因此，高性能的圖數(shù)據(jù)庫一定是優(yōu)先解決算力的問題，即具備高算力，讓計算引擎成為一等公民（注：在傳統(tǒng)的RDBMS數(shù)據(jù)庫中，計算是附著于存儲的二等公民，試想每次查詢都需要大量訪問硬盤讀取數(shù)據(jù)的查詢，效率必然是極低的！）。

圖數(shù)據(jù)庫賦能的業(yè)務場景也必然和傳統(tǒng)數(shù)據(jù)庫、大數(shù)據(jù)框架有所不同，無論是風控反欺詐、智能營銷與推薦，還是實時決策、智能分析（Smart BI/Analytics）、數(shù)據(jù)治理等場景。?