怎么利用Neo4j聯(lián)邦實現(xiàn)LDBC社交網(wǎng)絡(luò)分割,針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
目前成都創(chuàng)新互聯(lián)已為數(shù)千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬主機、網(wǎng)站托管運營、企業(yè)網(wǎng)站設(shè)計、蜀山網(wǎng)站維護等服務(wù),公司將堅持客戶導向、應用為本的策略,正道將秉承"和諧、參與、激情"的文化,與客戶和合作伙伴齊心協(xié)力一起成長,共同發(fā)展。Neo4j 4.0發(fā)布了一個令人興奮新功能:Neo4j聯(lián)邦。Neo4j聯(lián)邦的操作原理從本質(zhì)上講非常簡單,它提供了一種方式來執(zhí)行針對多個Neo4j數(shù)據(jù)庫的Cypher查詢。
可以通過多種方式來使用此功能,包括跨多個獨立數(shù)據(jù)庫的聯(lián)合查詢與分析,數(shù)據(jù)存儲和處理可以水平擴展,也可以進行不同的混合部署。
接下來,我們將探討如何使用聯(lián)邦功能來實現(xiàn)著名且具有挑戰(zhàn)性的LDBC社交網(wǎng)絡(luò)基準圖的水平縮放(即分片)。
對圖數(shù)據(jù)進行分片是一個眾所周知的難題。我們將展示如何使用Neo4j聯(lián)邦實現(xiàn)分片,Neo4j 聯(lián)邦將分片存儲為獨立和不相交的圖,這意味著關(guān)系不會跨越分片。而是使用我們稱為代理節(jié)點并關(guān)聯(lián)ID值的方法對此類關(guān)系進行建模。我們將依賴有關(guān)數(shù)據(jù)模型和將要運行的查詢以及要針對哪些查詢進行優(yōu)化的知識,以針對特定用例創(chuàng)建分片數(shù)據(jù)模型。
最后,我們將通過比較分片版本和非分片版本之間的查詢時間和吞吐量,展示聯(lián)邦功能如何提高查詢性能。
LDBC社交網(wǎng)絡(luò)基準提供了數(shù)據(jù)模型規(guī)范以及數(shù)據(jù)生成器,以及一組查詢規(guī)范。需要注意的是,我們并沒有使用基準所指定的基準工作負載,而是借用其數(shù)據(jù)模型和查詢來進行另一種演示。該測試旨在證明分片和非分片配置之間的差異,并探討圖形分片的注意事項,而不是提供行業(yè)基準。
在規(guī)范中可以找到LDBC SNB數(shù)據(jù)模型的完整描述。我們將在此處提供簡化的概述,并以導入到Neo4j中時架構(gòu)的外觀表示。
該模型包含一個由不同的人和他們的友誼關(guān)系組成的圖組件,并構(gòu)成了社交網(wǎng)絡(luò)的核心。就數(shù)據(jù)大小而言,該圖組件的大部分是留言板組件,該組件為包含帖子和評論回復鏈的論壇建模。人們可以通過多種不同方式與論壇,帖子和評論相關(guān)聯(lián)。
論壇,帖子和評論都有標簽,每個人都可以有一組代表其興趣的標簽。標簽是按類別進行分類的。不同的人位于不同國家(或地區(qū))的城市中,每個帖子或評論也在一個國家中創(chuàng)建
完整模型包含更多實體,例如大學,公司和大洲,我們暫時不在此描述。
分片數(shù)據(jù)模型始終是一個復雜的問題,沒有通用的解決方案。確定要“剪切”的關(guān)系不僅取決于模型本身,還取決于數(shù)據(jù)分布和預期的查詢執(zhí)行模式。
根據(jù)國家或地區(qū)進行分片似乎是自然的選擇。這種分片方案是基于這樣的假設(shè),即用戶更可能會認識來自同一國家的人并與之互動。詳細討論為什么這種分片方案在這種情況下是否是最佳的討論超出了本文的討論范圍。簡化的解釋是,典型的查詢將不得不在各個分片之間進行過多的“跳轉(zhuǎn)”。
在考慮了多種選擇之后,我們決定采用以下分片方案。
選擇的分片方案是異構(gòu)的,這意味著并非所有分片都包含相同種類的數(shù)據(jù)。所有個人和與他們相關(guān)的數(shù)據(jù)都保存在一個分片 中。論壇,其帖子和評論分布在其余分片上。地理數(shù)據(jù)和標簽結(jié)構(gòu)被復制到每個分片上。論壇分片包含簡化的人員代理節(jié)點表示形式,僅保留其原始id屬性
這種分片方案有兩個優(yōu)點。首先,它允許有效的查詢?nèi)伺c人之間的關(guān)系,這在許多查詢中至關(guān)重要。其次,由于論壇本質(zhì)上是一片森林,因此它們可以分布在其余分片上,而沒有最重要的關(guān)系跨越分片邊界。
將所有人放在一個片上不是問題,因為消息和評論要比個人信息多幾個數(shù)量級。從理論上講,如果社交網(wǎng)絡(luò)發(fā)展得飛快,以至于“人物”圖無法有效地安裝在一臺機器上,那么它可能會被進一步分割。
同樣,在所有分片上復制標簽,城市和國家也不成問題,因為這類數(shù)據(jù)非常小且靜態(tài)。
我們設(shè)計了許多測試方案,來評估上述分片模型的性能,尤其是針對非分片模型進行了比較,以及隨著分片數(shù)量的增加如何更改性能。此處重點關(guān)注的方案是查看在將數(shù)據(jù)集分配給越來越多的越來越小的分片時,讀取性能如何擴展。
我們要強調(diào)的是,我們只是借鑒了LDBC社交網(wǎng)絡(luò)基準測試的數(shù)據(jù)模型,數(shù)據(jù)生成器和查詢,但是測試執(zhí)行的目標和方法不同。
LDBC SNB指定許多查詢,分為若干類別。我們從“交互式復雜讀取”類別中選擇了四個查詢(查詢4,查詢6,查詢7和查詢9),它們代表了該工作負載,我們將在其上展示我們的結(jié)果。這些查詢的定義可以在LDBC SNB規(guī)范中找到。
這些查詢的聯(lián)邦Cypher實現(xiàn)可在此處找到。
接下來,我們將分享更多查詢以及其他有趣測試場景的結(jié)果。
我們的測試數(shù)據(jù)集是使用LDBC SNB數(shù)據(jù)生成器以比例因子(SF)1000生成的。它包含大約27億個節(jié)點。數(shù)據(jù)生成器創(chuàng)建的csv文件的大小約為1TB。
我們將生成的數(shù)據(jù)以四種不同的配置導入到Neo4j中
1個分片(無代理,整體參考)
10個分片(1個人員分片,9個論壇分片)
20個分片(1個人員分片,19個論壇分片)
40個分片(1個人員分片,39個論壇分片)
這些分片分別部署在各自獨立的AWS EC2實例上,并且在這些實例上運行Neo4j 4.0。配置內(nèi)存限制以使所有分片上的總可用量保持恒定,為1800GB。除了內(nèi)存限制,Neo4j實例具有默認設(shè)置。
#分片 | 分片實例類型 | 內(nèi)存(GB) | |||
總量 | 每個分片 | 頁面緩存 | 堆 | ||
1個 | x1.32xlarge(128C,1,952GB) | 1,800 | 1,800 | 1,600 | 200 |
10 | m5d.12xlarge(48C,192GB) | 1,800 | 180 | 160 | 20 |
20 | m5d.8xlarge(32C,128GB) | 1,800 | 90 | 80 | 10 |
40 | m5d.4xlarge(16C,64GB) | 1,800 | 45 | 40 | 5 |
查詢延遲是通過一次又一次執(zhí)行單個查詢來衡量的,同時記錄從提交到每個查詢結(jié)果執(zhí)行完畢所消耗的時間。查詢參數(shù)按照它們在LDBC參數(shù)文件中出現(xiàn)的順序提供給每個查詢執(zhí)行。初始的查詢執(zhí)行結(jié)果集被認為是“熱數(shù)據(jù)”,并且從統(tǒng)計信息中排除。聯(lián)邦代理部署在t3.2xlarge類型(8C,32GB)的單個單獨實例上
大查詢吞吐量是通過隨著時間的推移增加并發(fā)發(fā)出的查詢的數(shù)量來統(tǒng)計的,直至錯誤率或延遲開始超出定義的參數(shù)為止。聯(lián)邦代理部署在c5.24xlarge類型(96C,192GB)的單個單獨實例上
這些結(jié)果表明Q06和Q09比Q04和Q07重得多。我們可以看到,隨著分片數(shù)量的增加,繁重的查詢延遲大大減少(請注意,該圖具有對數(shù)刻度)。對于較輕的工作負載,由于通信開銷越來越占主導地位,因此延遲會按預期增加。盡管如此,我們?nèi)栽O(shè)法將Q04和Q07的毫秒延遲保持在較低水平。
仔細研究繁重的查詢,我們發(fā)現(xiàn)Q06在10個分片上的速度提高了約11倍,在20個分片上的速度提高了約17倍。這些極好的結(jié)果表明,如果分片數(shù)量合理,聯(lián)邦可以針對此類工作負載實現(xiàn)幾乎線性的加速。在相同的速度下,任何工作負載都無法無限并行化,而在40個分片上,我們的速度提高了約24倍。這些結(jié)果非常令人鼓舞,表明與聯(lián)邦并行執(zhí)行對延遲的影響遠大于通信和協(xié)調(diào)開銷。
延遲測量一次只能運行一個查詢。下圖顯示了并發(fā)吞吐能力,即每秒測得的大執(zhí)行查詢數(shù)。
同樣,我們看到了從單個實例到10個分片的驚人性能提升。有趣的是,當我們從單個實例到10個分片時,大吞吐量的增加比添加的處理器核心數(shù)量增加的更多。這可以用以下事實解釋:使用10臺計算機不僅增加了更多的處理器核心,而且還增加了其他資源,例如總內(nèi)存帶寬。
由于我們沒有辦法限制分片機上可用內(nèi)核的數(shù)量以平衡計算能力總量,因此以下圖顯示了將大QPS標準化為AWS EC2上整個設(shè)置的每小時總成本。
關(guān)于怎么利用Neo4j聯(lián)邦實現(xiàn)LDBC社交網(wǎng)絡(luò)分割問題的解答就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道了解更多相關(guān)知識。