怎么利用Neo4j聯邦實現LDBC社交網絡分割

怎么利用Neo4j聯邦實現LDBC社交網絡分割，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

什么是Neo4j聯邦以及水平分片

Neo4j 4.0發布了一個令人興奮新功能：Neo4j聯邦。Neo4j聯邦的操作原理從本質上講非常簡單，它提供了一種方式來執行針對多個Neo4j數據庫的Cypher查詢。

可以通過多種方式來使用此功能，包括跨多個獨立數據庫的聯合查詢與分析，數據存儲和處理可以水平擴展，也可以進行不同的混合部署。

接下來，我們將探討如何使用聯邦功能來實現著名且具有挑戰性的LDBC社交網絡基準圖的水平縮放（即分片）。

對圖數據進行分片是一個眾所周知的難題。我們將展示如何使用Neo4j聯邦實現分片，Neo4j 聯邦將分片存儲為獨立和不相交的圖，這意味著關系不會跨越分片。而是使用我們稱為代理節點并關聯ID值的方法對此類關系進行建模。我們將依賴有關數據模型和將要運行的查詢以及要針對哪些查詢進行優化的知識，以針對特定用例創建分片數據模型。

最后，我們將通過比較分片版本和非分片版本之間的查詢時間和吞吐量，展示聯邦功能如何提高查詢性能。

LDBC社交網絡基準概述

LDBC社交網絡基準提供了數據模型規范以及數據生成器，以及一組查詢規范。需要注意的是，我們并沒有使用基準所指定的基準工作負載，而是借用其數據模型和查詢來進行另一種演示。該測試旨在證明分片和非分片配置之間的差異，并探討圖形分片的注意事項，而不是提供行業基準。

資料模型

在規范中可以找到LDBC SNB數據模型的完整描述。我們將在此處提供簡化的概述，并以導入到Neo4j中時架構的外觀表示。

該模型包含一個由不同的人和他們的友誼關系組成的圖組件，并構成了社交網絡的核心。就數據大小而言，該圖組件的最大部分是留言板組件，該組件為包含帖子和評論回復鏈的論壇建模。人們可以通過多種不同方式與論壇，帖子和評論相關聯。

論壇，帖子和評論都有標簽，每個人都可以有一組代表其興趣的標簽。標簽是按類別進行分類的。不同的人位于不同國家（或地區）的城市中，每個帖子或評論也在一個國家中創建

完整模型包含更多實體，例如大學，公司和大洲，我們暫時不在此描述。

分片數據模型

分片數據模型始終是一個復雜的問題，沒有通用的解決方案。確定要“剪切”的關系不僅取決于模型本身，還取決于數據分布和預期的查詢執行模式。

根據國家或地區進行分片似乎是自然的選擇。這種分片方案是基于這樣的假設，即用戶更可能會認識來自同一國家的人并與之互動。詳細討論為什么這種分片方案在這種情況下是否是最佳的討論超出了本文的討論范圍。簡化的解釋是，典型的查詢將不得不在各個分片之間進行過多的“跳轉”。

在考慮了多種選擇之后，我們決定采用以下分片方案。

選擇的分片方案是異構的，這意味著并非所有分片都包含相同種類的數據。所有個人和與他們相關的數據都保存在一個分片 中。論壇，其帖子和評論分布在其余分片上。地理數據和標簽結構被復制到每個分片上。論壇分片包含簡化的人員代理節點表示形式，僅保留其原始id屬性

這種分片方案有兩個優點。首先，它允許有效的查詢人與人之間的關系，這在許多查詢中至關重要。其次，由于論壇本質上是一片森林，因此它們可以分布在其余分片上，而沒有最重要的關系跨越分片邊界。

將所有人放在一個片上不是問題，因為消息和評論要比個人信息多幾個數量級。從理論上講，如果社交網絡發展得飛快，以至于“人物”圖無法有效地安裝在一臺機器上，那么它可能會被進一步分割。

同樣，在所有分片上復制標簽，城市和國家也不成問題，因為這類數據非常小且靜態。

試驗結果

我們設計了許多測試方案，來評估上述分片模型的性能，尤其是針對非分片模型進行了比較，以及隨著分片數量的增加如何更改性能。此處重點關注的方案是查看在將數據集分配給越來越多的越來越小的分片時，讀取性能如何擴展。

我們要強調的是，我們只是借鑒了LDBC社交網絡基準測試的數據模型，數據生成器和查詢，但是測試執行的目標和方法不同。

查詢

LDBC SNB指定許多查詢，分為若干類別。我們從“交互式復雜讀取”類別中選擇了四個查詢（查詢4，查詢6，查詢7和查詢9），它們代表了該工作負載，我們將在其上展示我們的結果。這些查詢的定義可以在LDBC SNB規范中找到。

這些查詢的聯邦Cypher實現可在此處找到。

接下來，我們將分享更多查詢以及其他有趣測試場景的結果。

測量設置

我們的測試數據集是使用LDBC SNB數據生成器以比例因子（SF）1000生成的。它包含大約27億個節點。數據生成器創建的csv文件的大小約為1TB。

我們將生成的數據以四種不同的配置導入到Neo4j中

• 1個分片（無代理，整體參考）

• 10個分片（1個人員分片，9個論壇分片）

• 20個分片（1個人員分片，19個論壇分片）

• 40個分片（1個人員分片，39個論壇分片）

這些分片分別部署在各自獨立的AWS EC2實例上，并且在這些實例上運行Neo4j 4.0。配置內存限制以使所有分片上的總可用量保持恒定，為1800GB。除了內存限制，Neo4j實例具有默認設置。

延遲測量

查詢延遲是通過一次又一次執行單個查詢來衡量的，同時記錄從提交到每個查詢結果執行完畢所消耗的時間。查詢參數按照它們在LDBC參數文件中出現的順序提供給每個查詢執行。初始的查詢執行結果集被認為是“熱數據”，并且從統計信息中排除。聯邦代理部署在t3.2xlarge類型（8C，32GB）的單個單獨實例上

吞吐量測量

最大查詢吞吐量是通過隨著時間的推移增加并發發出的查詢的數量來統計的，直至錯誤率或延遲開始超出定義的參數為止。聯邦代理部署在c5.24xlarge類型（96C，192GB）的單個單獨實例上

結果

這些結果表明Q06和Q09比Q04和Q07重得多。我們可以看到，隨著分片數量的增加，繁重的查詢延遲大大減少（請注意，該圖具有對數刻度）。對于較輕的工作負載，由于通信開銷越來越占主導地位，因此延遲會按預期增加。盡管如此，我們仍設法將Q04和Q07的毫秒延遲保持在較低水平。

仔細研究繁重的查詢，我們發現Q06在10個分片上的速度提高了約11倍，在20個分片上的速度提高了約17倍。這些極好的結果表明，如果分片數量合理，聯邦可以針對此類工作負載實現幾乎線性的加速。在相同的速度下，任何工作負載都無法無限并行化，而在40個分片上，我們的速度提高了約24倍。這些結果非常令人鼓舞，表明與聯邦并行執行對延遲的影響遠大于通信和協調開銷。

延遲測量一次只能運行一個查詢。下圖顯示了并發吞吐能力，即每秒測得的最大執行查詢數。

同樣，我們看到了從單個實例到10個分片的驚人性能提升。有趣的是，當我們從單個實例到10個分片時，最大吞吐量的增加比添加的處理器核心數量增加的更多。這可以用以下事實解釋：使用10臺計算機不僅增加了更多的處理器核心，而且還增加了其他資源，例如總內存帶寬。

由于我們沒有辦法限制分片機上可用內核的數量以平衡計算能力總量，因此以下圖顯示了將最大QPS標準化為AWS EC2上整個設置的每小時總成本。

關于怎么利用Neo4j聯邦實現LDBC社交網絡分割問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。