圖數據庫是數據管理系統軟件。構建塊是頂點和邊緣。為了將其置于更熟悉的上下文中，關系數據庫也是一種數據管理軟件，其中構建塊是表。兩者都需要將數據加載到軟件中并使用查詢語言或API來訪問數據。關系數據庫在20世紀80年代蓬勃發展。許多商業公司（即Oracle，Ingres，IBM）支持數據管理的關系模型（表格組織）。在那個時代，主要的數據管理需求是生成報告。

直到最近幾年，頻繁的模式更改，管理爆炸物數據量，實時查詢響應時間以及更智能的數據激活要求使得人們意識到圖模型的優勢，圖形數據庫并沒有比關系數據庫看到更大的優勢。

有許多商業軟件公司支持這種模式，包括TigerGraph（以前稱為GraphSQL），Neo4j和DataStax。該技術正在擾亂許多領域，例如供應鏈管理，電子商務建議，安全性，欺詐檢測，公用電網調度，AI應用知識圖，區塊鏈總分類數據的分析查詢以及高級數據分析中的許多其他領域。有關詳細說明，請參閱此頁面 和此頁面。

這意味著您編寫的每個查詢都有非常清晰，明確的語義。沒有隱藏的假設，例如關系SQL，您必須知道FROM 子句中的表將如何 隱式形成笛卡爾積。除了易于使用之外，例如常規路徑模式匹配，累加器概念允許精細控制以保持數據的中間查詢狀態。

它們具有優異的性能，可用于查詢相關數據，無論大小。圖表本質上是索引數據結構。它永遠不需要加載或觸摸給定查詢的不相關數據。它們是實時大數據分析查詢的絕佳解決方案。

圖形數據庫解決了對于關系查詢而言既不切實際又不實用的問題。示例包括迭代算法，如PageRank，梯度下降，以及其他數據挖掘和機器學習算法。研究證明，一些圖形查詢語言是圖靈完備的，這意味著你可以在它們上面編寫任何算法。然而，市場上有許多查詢語言具有有限的表達能力。確保你提出許多假設性問題，看看它是否可以在你鎖定之前回答它們。

圖形數據庫可以在同時支持查詢的同時對大數據執行實時更新。這是現有大數據管理系統（如Hadoop HDFS）的一個主要缺點，因為它是專為數據湖設計的，其中順序掃描和附加新數據（無隨機搜索）是預期工作負載的特征，它是架構設計的選擇確保整個文件的快速掃描I / O. 假設任何查詢都會觸及文件的大部分，而圖形數據庫只觸及相關數據，因此順序掃描不是優化假設。

圖形數據庫在為您的查詢提供服務時提供靈活的在線模式演變。您可以不斷添加和刪除新的頂點或邊緣類型或其屬性，以擴展或縮小數據模型。大多數現有查詢仍然有效！管理爆炸性和不斷變化的對象類型非常方便。關系數據庫無法輕易地適應這一要求，這在現代數據管理時代是司空見慣的。

許多有用的現實查詢都是在圖形（或數據網絡）中找到直接和間接的連接?；卮疬@類可達性查詢是圖數據庫的核心功能之一。例如，給予公司，找到誰直接或間接投資公司。另一個例子，給定產品，找到與產品直接或間接相關的任何子部分。

此外，我們可以使用共享一些公共頂點的多個可達性查詢來擴展單對頂點可達性查詢?？梢詫⒁唤M可達性路徑查詢捆綁在一起以相互約束以形成有趣的子圖模式。這就是所謂的聯合圖查詢（CQ）。CQ允許用戶提出子圖模式并要求數據庫返回與此模式匹配的所有子圖實例。例如，給予公司，找到直接或間接投資公司的投資者； 投資者與公司的創始人有直接或間接的聯系。

在關系數據庫中很難做到可達性查詢，因為沒有預定數量的JOIN。如果我們根據路徑的某些測量值對連接（路徑）進行排序會變得更加困難。例如，找到兩個城市之間所有航班時刻表的短路徑; 在社交圖上找到對我來說距離最短的人可以將我連接到某個目標用戶等。在圖查詢語言的邊緣模式中使用正則表達式來表達這類遞歸路徑查詢很容易。相比之下，即使使用SQL 99 遞歸子句，在SQL中執行此操作也非常困難。

除了傳統的分組查詢之外，圖形數據庫可以通過在關系數據庫中難以想象或不切實際的聚合查詢來執行某些類別的組。由于表格模型限制，關系數據庫上的聚合查詢受到數據如何組合在一起的極大限制。相比之下，圖模型可以更靈活地進行分組和聚合相關數據?？吹竭@篇文章 關于使用累加器進行圖遍歷的聚合的最新表現力（頂點和邊的運行時屬性，或查詢的全局狀態）。我認為關系數據庫不能對選擇性數據點進行這種靈活的聚合。

圖形數據庫可以組合多個維度來管理大數據，包括時間序列，人口統計，地理維度等，以及不同維度的粒度層次結構。考慮一下我們想要根據時間和地理維度對一組人口進行分段的應用程序。通過精心設計的圖表架構，數據科學家和業務分析師幾乎可以對圖形數據庫進行任何分析查詢。傳統上，此功能只能由低級編程語言（如C ++和Java）訪問。一系列精彩的網絡研討會使這一點更加清晰。