圖數據庫與關係數據庫的實驗對比——意大利商會 InfoCamere 案例

實驗案例由 Luca Sinico (InfoCamere 軟件開發人員) 負責編寫 

實驗概述

InfoCamere 於二零一六年下半年展開圖形數據庫領域的檢驗工做，工做的目的是對該技術的主要特性進行調查; 在概念和性能方面比較市場上的一些可用產品以及關係解決方案;並檢查一些InfoCamere應用程序的圖形數據庫的採用可能性。這項工做是基於意大利企業註冊摘要得到的數據集，幷包含有關企業參股的數據。圖的節點能夠是天然人或公司，而且收集關於面額，公司的股本，註冊國家，惟一的財政標識符等的數據。圖的邊緣表明其中的股權參與。

在咱們的工做中，咱們檢查了兩種主要類型的圖形數據模型，即「屬性圖」和「RDF」。儘管RDF（W3C標準）表明了實現連接數據和語義Web的有效方法，儘管它以圖形的形式組織數據，可是咱們發現屬性圖模型（一種「行業標準」）能更好地知足咱們的要求。實際上，它容許在邊上定義屬性。而RDF不容許直接使用它。另外，針對RDF（SPARQL）提出的標準查詢語言對於一般由支持「屬性圖」模型的DBMS提供的查詢語言顯示出一些限制。兩個簡單的例子是缺乏最短路徑計算函數，而且可能爲可變長度路徑搜索表示最大深度級別。

數據進入圖形數據庫的流程如圖2所示。從存儲意大利商業註冊的複雜關係數據庫開始，經過用戶需求或更新操做不斷產生一些標題搜索。標題搜索保存經過組合不一樣表中的不一樣記錄得到的彙總數據，這對於某些應用是有用的。正由於如此，這些數據放在關係數據庫上以支持其操做。因爲這個第二關係數據庫主要集中在與公司參股相關的方面，圖形數據庫從中獲取數據。

查詢

咱們開發的查詢能夠被這些數據集上的應用程序所使用，也能夠稍微強調數據庫管理系統的能力。特別是咱們開發了一些標準查詢和一些更具體的查詢。
鑑於一個特定的公司，由其「財政ID」肯定，咱們要求其員工;它的參與;或二者同時;從而經過將搜索限制到僅一個深度級別。可是，咱們也要求直接和間接參與一家公司（一樣也是爲了同事）。這對應於沒有深度限制的圖的探索。此外，因爲數據集構成一個圖（而不是「簡單」樹），兩家公司之間的路徑多是多個。這使咱們要求提供鏈接兩家公司的完整的直接路徑列表;或者，也能夠是最短的一個。咱們還要求兩家公司的共同參與（或同事）。數據集的圖形性質也致使了另外兩個查詢的制定：第一個返回與檢索到的參與節點一塊兒, 而且檢索到的深度值下降; 第二個查詢計算每一個深度級別的與給定節點的關聯公司，可是避免對它們進行屢次計數。
查詢的開發有助於調查目的和更好的數據探索體驗。

圖形數據庫與關係數據庫的比較

咱們將數據集導入了三個最知名的圖形數據庫，分別是ArangoDB v3.0.10; Neo4j v3.0.6;和OrientDB v2.2.11（均爲社區版）。咱們還將數據集導入了一個衆所周知的關係數據庫：PostgreSQL v9.6.1。關係型數據庫的選擇沒有強烈的約束，由於性能主要受SQL語言性能的影響。這些產品已經安裝在虛擬服務器上，資源適中，所以對於其餘相似硬件可用性的公司來講，結果也是有用的。對於每一種查詢，咱們選擇了三個表明三種不一樣負載的DBMS的三個節點。特別是：一個節點表示一個輕量級的案例，可能較少的返回的結果，或者較短的勘探深度值; 一個節點表明中間的案例; 還有一個重量級的案例。咱們不止一次地執行了這些查詢，因此咱們也研究了延遲加載的緩存之間的性能差別。

因爲目前尚未圖形數據庫的標準查詢語言，所以每一個圖形DBMS都提供本身的查詢語言。這促使咱們評估各類查詢語言的表達性和易用性。

結果

咱們收集的結果歸納以下：

• 圖表數據庫提供了一些特地設計的查詢語言，這些語言大大有助於描述圖遍歷查詢，也有助於應對該領域的一些典型計算問題。使用SQL或藉助存儲過程，相同的查詢很難以高效的方式實現。
• 雖然關係數據庫對較簡單的查詢執行得很好，但對於圖挖掘查詢的重量級案例（即那些有大量待分析節點的數據，並須要遍歷的高水平的值），分析顯示三個圖數據庫的性能一般要比關係型數據庫高出一個或兩個數量級。
• ArangoDB顯示了良好的導入和查詢性能，尤爲適用於輕量級和中等工做負載的狀況。
• 關於ArangoDB 測試版本的關注點之一就是內存佔用 RAM greedy。然而，ArangoDB聲稱已經用他們新的3.2版本和新的RocksDB存儲引擎解決了這個「問題」。

實驗結論

因爲在研究工做中獲得了良好的反饋，在導入和執行時間方面表現良好，文檔良好，易於使用和商業價格合理，ArangoDB 在InfoCamere 的一些應用程序中表現出了很好的潛力。最終，咱們決定在咱們正在開發的演示應用程序中使用ArangoDB。

關於比較實驗的一些額外細節能夠在這裏找到。

英文原文連接