導讀 小紅書作為一個社群屬性為主的産品，涵蓋了各個領域的生活社群，并存儲海量的社交網絡關系。為了解決社交場景下的應用痛點以及分布式并行查詢實作中的問題，我們自研了面向超大規模社交網絡的圖資料庫系統 REDgraph，大大提高了系統的查詢效率和性能。
本次分享的内容主要包括五個部分：
1. 背景介紹
2. 原架構問題分析
3. 分布式并行查詢實作
4. 總結與展望
5. 問答環節
分享嘉賓｜李凝瑞（薯名：再興） 小紅書 分布式資料庫架構師
編輯整理｜張進東
内容校對｜李瑤
出品社群｜DataFun
01
背景介紹
1. 圖資料庫介紹
關于圖資料庫的概念，這裡不作詳細闡述。而是以圖表的形式，對其與另外幾種 NoSQL 産品進行比較。圖資料庫本身歸屬于 NoSQL 存儲，而諸如KV 類型、寬表類型、文檔類型、時序類型等其他 NoSQL 産品，各自具備獨特的特性。從上圖左側的坐标軸中可以看到，從 KV 到寬表、文檔，再到圖，資料關聯度和查詢複雜度是越來越高的。前三者，即 KV、寬表和文檔，主要關注的是單個記錄内部的豐富性，但并未涉及記錄間的關系。而圖資料庫則專注于處理這些關系。圖資料庫主要适用于需要挖掘深鍊路或多元度關系的業務場景。
接下來通過一個具體示例，再來對比一下圖資料庫與關系型資料庫。這是社交網絡中常見的一種表結構，包括四個資料表：使用者表、好友關系表、點贊行為表以及筆記詳情表。比如要查詢 Tom 這個使用者的好友所點贊的筆記的詳細資訊，那麼可能需要編寫一段冗長的 SQL 語句。在該 SQL 語句中，涉及到三個 join 操作，首先将使用者表和好友關系表進行連接配接，進而擷取 Tom 的所有好友資訊。然後，将得到的中間結果與點贊行為表進行連接配接，以确定 Tom 的好友都點贊了哪些筆記。最後，還需要對先前生成的臨時表和筆記詳情表進行連接配接，以便最終擷取這些筆記的全部内容。
關系型資料庫中的 join 操作通常複雜度較高，其執行過程中需消耗大量的 CPU 資源、記憶體空間以及 IO，雖然我們可以通過精心的設計，例如針對所要關聯的列建立索引，以降低掃描操作的比例，通過索引比對來實作一定程度的性能提升。然而，這樣的舉措所産生的成本相對較高，因為所有新的場景都需要建立索引，要考慮如何撰寫 SQL 中的 join 條件，選擇哪個表作為驅動表等等，這些都需要耗費大量的精力和時間。
而如果采用圖資料庫，則會簡單很多。首先進行圖模組化，建立兩類頂點，分别為使用者和筆記，同時建立兩類邊，一類是好友關系，即使用者到使用者的邊；另一類是使用者到筆記的點贊關系。當我們将這些資料存儲到圖資料庫中時，它們在邏輯上呈現出一種網狀結構，其關聯關系已經非常明确。查詢時，如上圖中使用 Gremlin 語句，僅需四行代碼即可擷取到所需的資訊。其中第一行 g.V().has('name', 'Tom')，用于定位 Tom 節點，兩個 out 子句，第一個 out 子句用于查找 Tom 的好友，第二個 out 子句用于查找 Tom 的點贊筆記。當第二個 out 子句執行完畢後，就可以周遊所有外部的綠色頂點，即筆記節點。最後，讀取它們的 content 屬性。可以發現，與關系型資料庫相比，圖資料庫的查詢語句更加簡潔、清晰易懂。
此外，圖資料庫還有一個更為顯著的優勢，就是在存儲時，它已經将頂點及其關系作為一等公民進行設計和存儲，是以在進行鄰接邊通路和關系提取時，效率極高。即使資料規模不斷擴大，也不會導緻查詢時間顯著增加。
2. 圖資料庫在小紅書的使用場景
小紅書是一個年輕的生活方式共享平台。在小紅書，使用者可以通過短視訊、圖檔等方式，直覺地記錄生活的點點滴滴。在小紅書内部，圖資料庫被廣泛應用于多種場景中，下面将分别列舉線上、近線以及離線場景的執行個體。
第一個案例是社交實時推薦功能。小紅書具有典型的社群特性，使用者可以在其中點贊、釋出貼文、關注他人、轉發資訊等。譬如我進入某使用者首頁并停留了較長時間，那麼系統便會判定我對該使用者有興趣，而這個使用者可能同樣吸引了他人的注意。是以，系統會将該使用者的其他關注者以及他們所關注的其他使用者推薦給我，因為我們有共同的興趣愛好，是以他們的關注内容我也有可能感興趣，這便是一種簡單的實時推薦機制。
第二個案例是社群風控機制，小紅書社群會對優質筆記或優質視訊的創作者進行獎勵，但這也給了一些羊毛黨可乘之機，他們釋出一些品質較低的文章或筆記，将其釋出在互刷群中，或者轉發給親朋好友，讓他們點贊和轉發，進而僞裝成所謂的高品質筆記，以此來騙取平台的獎勵。社群業務部門擁有一些離線算法，能夠對已有的資料進行分析，識别出哪些使用者和筆記屬于作弊使用者，在圖中用紅色的點标出。在近線場景中，系統會判斷每個頂點在多跳關系内接觸到的作弊使用者的數量或比例，如果超過一定的門檻值，則會将這個人标記為潛在的風險使用者，即黃色的頂點，進而采取防範措施。
第三個案例是離線任務的排程問題，在大資料平台中，往往存在大量的離線任務，而任務之間的依賴關系錯綜複雜，如何合理地排程任務，成為一個棘手的問題。圖結構非常适合解決這類問題，通過拓撲排序或其他算法，可以找出最受依賴的任務，并進行反向推理。
3. 業務上面臨的困境
小紅書在社交、風控及離線任務排程等場景中均采用了圖資料庫，然而在實際應用過程中遇到了諸多挑戰。在此，簡要介紹其中基于實時推薦場景的一個痛點。
業務訴求是能即時向使用者推送可能感興趣的“好友”或“内容”，如圖所示，A 與 F 之間僅需經過三次跳躍即可到達，是以 A 與 F 構成了一種可推薦的關聯關系，如果能即時完成此推薦，則能有效提升使用者使用體驗，提升留存率。然而，由于先前 REDgraph 在某些方面的能力尚未完善，業務一直隻采用了一跳和兩跳查詢，未使用三跳，風控場景也是類似。
業務對時延的具體要求為，社交推薦要求三跳的 P99 低于 50 毫秒，風控則要求三跳的 P99 低于 200 毫秒，這是目前 REDgraph 所面臨的一大難題。
那為何一至二跳可行，三跳及以上就難以實作呢？對此，我們基于圖資料庫與其他類型系統在工作負載的差異，做了一些難點與可行性分析。
首先在并發方面，OLTP 的并發度很高，而 OLAP 則相對較低。圖的三跳查詢，服務的仍然是線上場景，其并發度也相對較高，這塊更貼近 OLTP 場景。
其次在計算複雜度方面，OLTP 場景中的查詢語句較為簡單，包含一到兩個 join 操作就算是較為複雜的情況了，是以，OLTP 的計算複雜度相對較低。OLAP 則是專門為計算設計的，是以其計算複雜度自然較高。圖的三跳查詢則介于 OLTP 和 OLAP 之間，它雖不像 OLAP 那樣需要執行大量的計算，但其通路的資料量相對于 OLTP 來說還是更可觀的，是以屬于中等複雜度。
第三，資料時效性方面，OLTP 對時效性的要求較高，必須基于最新的資料提供準确且實時的響應。而在 OLAP 場景中則沒有這麼高的時效要求，早期的 OLAP 資料庫通常提供的是 T+1 的時效。圖的三跳查詢，由于我們服務的是線上場景，是以對時效性有一定的要求，但并不是非常高。使用一小時或 10 分鐘前的狀态進行推薦，也不會産生過于嚴重的後果。是以，我們将其定義為中等時效性。
最後，查詢失敗代價方面。OLTP 一次查詢的成本較低，是以其失敗的代價也低；而 OLAP 由于需要消耗大量的計算資源，是以其失敗代價很高。圖查詢在這塊，更像 OLTP 場景一些，但畢竟通路的資料量較大，是以同樣歸屬到中等。
總結一下：圖的三跳查詢具備 OLTP 級别的并發度，卻又有比一般 OLTP 大得多的資料通路量和計算複雜度，是以比較難在線上場景中使用。好在其對資料時效性的要求沒那麼高，也能容忍一些查詢失敗，是以我們能嘗試對其優化。
正如前面提到的，在小紅書，三跳查詢的首要目标還是降低延遲。有些系統中會考慮犧牲一點時延來換取吞吐的大幅提升，而這在小紅書業務上是不可接受的。如果吞吐上不去，還可以通過擴大叢集規模來兜底，而如果時延高則直接不能使用了。
02
原架構問題分析
第二部分将詳述原體系結構中所存在的問題及其優化措施。
1. RedGraph 整體架構
REDgraph 的整體結構如上圖所示，其與目前較為流行的 NewSQL，如 TiDB 的架構構相似。采用了存儲和計算分離的架構，并且存儲是 shared-nothing 的。三類節點分别為 meta-server，元資訊的管理；query-server，使用者查詢請求的處理；store-server，存儲資料。
2. RedGraph 圖切分方式
圖切分的含義為，如果我們擁有一個巨大的圖，規模在百億到千億水準，應該如何将其存儲在分布式叢集之中，以及如何對其進行切分。在工業界中，主要存在兩種典型的切分政策，即邊切分和點切分。
邊切分，以頂點為中心，這種切分政策的核心思想是每個頂點會根據其 ID 進行哈希運算，并将其路由到特定的分片上。每個頂點上的每條邊在磁盤中都會被存儲兩份，其中一份與起點位于同一分片，另一份則與終點位于同一分片。如上圖中的例子，其中涉及到 ABC 三個頂點的哈希定位結果。在這個例子中，A 至 C 的這條出邊，被放置在與 A 同一個節點上。同樣，B 至 C 的出邊跟 B 放到了一起，最後一個桶中儲存了 C 以及 C 的入邊，即由 A 和 B 指向 C 的兩條入邊。
點切分，與邊切分相對應，以邊為中心，每個頂點會在叢集内儲存多份。
這兩種切分方式各有利弊。邊切分的優點在于每個頂點與其鄰居都儲存在同一個分片中，是以當需要查詢某個頂點的鄰居時，其通路局部性極佳；其缺點在于容易負載不均，且由于節點分布的不均勻性，引發熱點問題。點切分則恰恰相反，其優點在于負載較為均衡，但缺點在于每個頂點會被切成多個部分，配置設定到多個機器上，是以更容易出現同步問題。
REDgraph 作為一個線上的圖查詢系統，選擇的是邊切分的方案。
3. 優化方案 1.0
我們之前已經實施了一些優化，可以稱之為優化方案 1.0。當時主要考慮的是如何快速滿足使用者需求，是以我們的方案包括：首先根據常用的查詢模式提供一些定制化的算法，這些算法可以跳過解析、校驗、優化和執行等繁瑣步驟，直接處理請求，進而實作加速。其次，我們會對每個頂點的扇出操作進行優化，即每個頂點在向外擴充時，對其擴充數量進行限制，以避免超級點的影響，降低延遲時間。此外，我們還完善了算子的下推政策，例如 filter、sample、limit 等，使其盡可能在存儲層完成，以減少網絡帶寬的消耗。同時，我們還允許讀從節點、讀寫線程分離、提高垃圾回收頻率等優化。
然而，這些優化政策有一個共性，就是每個點都比較局部化和零散，是以其通用性較低。比如第一個優化，如果使用者需要發起新的查詢模式，那麼此前編寫的算法便無法滿足其需求，需要另行編寫。第二個優化，如果使用者所需要的是頂點的全部結果，那此項也不再适用。第三個優化，如果查詢中本身就不存在這些運算符，那麼自然也無法進行下推操作。諸如此類，通用性較低，是以需要尋找一種更為通用，能夠減少重複工作的優化政策。
4. 新方案思考
如上圖中，是對一個耗時接近一秒的三跳查詢的 profile 分析。我們發現在每一跳産出的記錄數量上，第一跳至第二跳擴散了 200 多倍，第二跳至第三跳擴散了 20 多倍，表現在結果上，需要計算的資料行數從 66 條直接躍升至 45 萬條，産出增長速度令人驚訝。此外，我們發現三跳算子在整個查詢過程中占據了較大的比重，其在查詢層的耗時更是占據了整個查詢的 80% 以上。
那麼應該如何進行優化呢？在資料庫性能優化方面，有許多可行的方案，主要分為三大類：存儲層的優化、查詢計劃的優化以及執行引擎的優化。
由于耗時大頭在查詢層，是以我們重點關注這塊。因為查詢計劃的優化是一個無止境的工程，使用者可能會寫出各種查詢語句，産生各種算子，難以找到一個通用且可收斂的方案來覆寫所有情況。而執行引擎則可以有一個相對固定的優化方案，是以我們優先選擇了優化執行引擎。
圖資料庫的核心就是多跳查詢執行架構，而其由于資料量大，計算量大，導緻查詢時間較長，是以我們借鑒了 MPP 資料庫和其他計算引擎的思想，提出了分布式并行查詢的解決方案。
原有的多跳查詢執行流程如上圖所示。假設我們要查詢933 頂點的三跳鄰居節點 ID，即檢索到藍圈中的所有頂點。經過查詢層處理後，将生成右圖所示執行計劃，START 表示計劃的起點，本身并無實際操作。GetNeighbor 算子則負責實際查詢頂點的鄰居，例如根據 933 找到 A 和 B。後續的 Project、InnerJoin 以及 Project 等操作均為對先前産生的結果進行資料結構的轉換、處理及裁剪等操作，以確定整個計算流程的順利進行。正是後續的這幾個算子耗費的時延較高。
算子的實體執行過程如上圖所示。查詢伺服器（Query Server）執行 START 指令後，将請求發送至存儲節點（Store Server）中的一個，該節點擷取其鄰居資訊，并回報至查詢層。查詢層接收到結果後，會對其中的資料進行去重或其他相關處理，然後再次下發，此次的目标是另外兩個 Store Server。這一步驟即為擷取二度鄰居的資訊，傳回至查詢層後，再對這些結果進行彙總和去重處理，如此往複。
在整個流程中，我們明顯觀察到三個問題。首先，圖中藍色方框内的算子都是串行運作的，必須等待前一個計算完成後，才能執行下一個。對于大規模的資料，串行執行的效率顯然無法與并行執行相提并論。其次，Query Server 内部存在一個同步點，即左側标注為紅色的字（等待所有響應傳回），要求 query Server 等待所有存儲節點的響應傳回後，才能繼續執行後續操作。若某一存儲節點的資料量較大或負載過高，導緻響應速度較慢，則會耗費大量時間在等待上，是以我們考慮取消同步等待的過程。最後，存儲層的結果需要先轉發回查詢層進行簡單處理，然後再向下發送，這無疑增加了不必要的轉發成本。如果存儲節點（Store Server）能夠自行轉發，便可避免一次網絡轉發過程，進而降低開銷。
相應的解決政策便是三點：算子并行執行，取消同步點，以及讓 Store Server 的結果直接轉發。基于此，我們提出了如下的改造思路。
首先，查詢伺服器（Query Server）将整個執行計劃以及執行計劃所需的初始資料傳輸至存儲伺服器（Store Server），之後 Store Server 自身來驅動整個執行過程。以 Store Server 1 為例，當它完成首次查詢後，便會根據結果 ID 所在的分區，将結果轉發至相應的 Store Server。各個 Store Server 可以獨立地繼續進行後續操作，進而實作整個執行動作的并行化，并且無同步點，也無需額外轉發。
需要說明的是，圖中右側白色方框比左側要矮一些，這是因為資料由上方轉到下方時，進行了分區下發，必然比在查詢伺服器接收到的總資料量要少。
可以看到，在各部分獨立驅動後，并未出現等待或額外轉發的情況，Query Server 隻需在最後一步收集各個 Store Server 的結果并聚合去重，然後傳回給用戶端。如此一來，整體時間相較于原始模型得到了顯著縮短。
03
分布式并行查詢實作
分布式并行查詢的具體實作，涉及到多個關鍵元素。接下來介紹其中一些細節。
1. 如何保證不對 1-2 跳産生負優化
首先一個問題是，在進行改造時如何確定不會對原始的 1-2 跳産生負優化。在企業内部進行新的改造和優化時，必須謹慎評估所采取的措施是否會對原有方案産生負優化。我們不希望新方案還未能帶來收益，反而破壞了原有的系統。是以，架構總體上與原來保持一緻。在 Store Server 内部插入了一層，稱為執行層，該層具有網絡互聯功能，主要用于分布式查詢的轉發。Query Server 層則基本保持不變。
這樣，當接收到使用者的執行計劃後，便可根據其跳數選擇不同的處理路徑。若為 1 至 2 跳，則仍沿用原有的流程，因為原有的流程能夠滿足 1-2 跳的業務需求，而 3 跳及以上則采用分布式查詢。
2. 如何與原有執行架構相容
第二個關鍵問題是如何維持與原有執行架構的相容性，即在進行分布式技術改造時，不希望對原有代碼進行大幅修改，而希望通過最小化的調整達到目的。這裡參考了其他産品的一些思路，具體來說，就是在一些需要切換分區通路的算子（如 GetNeighbor 等）之前，添加具有路由功能的算子。這裡有三種，分别為 Forward、Converge 和 Merge。Forward 的作用顯而易見，即當遇到任何運算符時，表示資料需要轉發給其他節點處理，而目前節點無法繼續處理。Converge 運算符則是在整個執行計劃的最後一步添加，用于訓示最終結果應傳回至最初接收使用者請求的節點。在 Converge 後，還需添加一個 Merge 運算符，該節點在收到結果後需要進行聚合操作，然後才能将結果傳回給用戶端。如此修改後，我們隻需實作這三個算子本身，無需對其他算子進行任何修改，且不會對網絡層造成幹擾，實作了極輕量級的改造。在執行計劃修改的過程中，我們還進行了一些額外的優化，例如将 GroupBy、OrderBy 等算子也進行了下推處理。
3. 如何做熱點處理
第三問題是如何進行熱點處理，或者說是重複 ID 的處理。當整個執行流程改造成由 Store Server 自行驅動之後，會出現一種情況，例如邊 AC 和邊 BC 位于兩個不同的 Store Server 上，查詢都是單跳的操作，可能左側的機器查詢 AC 操作更快，而右側的機器查詢 BC 操作較慢，是以導緻左側的機器首先查找到 C，然後将結果轉發給其他機器，向下一級中間機器查詢 C 的鄰居，即執行 GetNeighbor from C，右側的節點雖然稍顯滞後，但也需要執行查詢 C 鄰居操作。
若不進行任何操作，在中間節點便會對 C 的鄰居進行兩次查詢，造成資源浪費。優化政策非常簡單，即在每個存儲節點之上添加 NeighborCache。本質是這樣一個 Map 結構，每當讀請求到來時，首先在 Map 中查找是否存在 C 的鄰節點，若存在則擷取，否則再通路存儲層，通路完畢後填充 NeighborCache 的條目，每個條目的生存時間都非常短暫。之是以短暫，其充分性在于左右節點送出請求的間隔肯定不會很久，不會達到數秒的級别，否則業務上也無法承受。是以，NeighborCache 的每個條目也隻需存活在秒級，超過則自動删除。必要性則在于 Map 的 Key 的組合模式，即 Vid+edgeType 這種組合模式還是非常多的，若不及時清理，記憶體很容易爆炸。此外，查詢層從 Disk Store 中查詢到資料并向 NeighborCache 回填時，也需進行記憶體檢查，以避免 OOM。
4. 如何做負載均衡
第四個問題是怎麼做負載均衡，包括兩塊，一個是存儲的均衡，另一個是計算的均衡。
首先存儲的均衡在以邊切分的圖存儲裡面其實是很難的，因為它天然的就是把頂點和其鄰居全部都存在了一起，這是圖資料庫相比其他資料庫的優勢，也是其要承擔的代價。是以目前沒有一個徹底的解決方法，隻能在真的碰到此問題時擴大叢集規模，讓資料的哈希打散能夠更加均勻一些，避免多個熱點都落在同一個機器的情況。而在目前的業務場景上來看，其實負載不均衡的現象不算嚴重，例如風控的一個比較大的叢集，其磁盤用量最高和最低的也不超過 10%，是以問題其實并沒有想象中的那麼嚴重。
另外一個優化方法是在存儲層及時清理那些過期的資料，清理得快的話也可以減少一些不均衡。
計算均衡的問題。存儲層采用了三副本的政策，若業務能夠接受弱一緻的讀取（實際上大多數業務均能接受），我們可以在請求轉發時，檢視三副本中的哪個節點負載較輕，将請求轉發至該節點，以盡量平衡負載。此外，正如前文所述，熱點結果緩存也是一種解決方案，隻要熱點處理速度足夠快，計算的不均衡現象便不易顯現。
5. 如何做流程控制
接下來的問題是如何進行流程控制。執行流程轉變為由 Store Server 自行驅動之後，僅第一個 Stage 有 Driver 參與，而後續步驟則由 Worker 之間互相傳輸和控制。那麼，Driver 應如何了解目前執行的階段以及其對應的某個 Stage 何時可以開始執行呢？有一種解決方案便是要求每一個 Worker 在接收到請求後或下發請求後，向 Driver 回傳一個響應，如此便可在 Driver 内記錄所有節點的進度資訊，這是可行的。
然而，此設計方案較重，因為 driver 并不需要深入了解每個節點的具體狀态，它僅需判斷自身是否具備執行條件，是以在工程實作中，我們采取了更為輕便的方式，即每個 Stage 生成一個 32 位的二進制數字 reqId，将其發送至 ACKer 确認器以傳達相關資訊。Acker 也以 32 位整數形式記錄該資訊，Stage1 同樣會接收到 Stage 0 發來的 reqId，經過内部一系列處理後，它會将接收到的 reqId 與自身生成的 3 個 reqId 進行異或運算，并将異或結果再次發送至确認器。由于異或操作的特性，當兩個數相同時，結果為 0，是以，當 0010 數進行異或運算後，這部分将變為 0。這就意味着 Stage 0 已經執行完畢。後續的所有階段均采用類似的方式，當确認器的結果再次變為 0 時，表示整個執行流程已經完成，即前面的 Stage 0 至 Stage 3 已經讀取完畢，此時可以執行 Stage 4，進而實作流程驅動。
另一個重要的問題便是全程鍊路的逾時自檢，例如在 Stage2 或 Stage3 的某一個節點上運作時間過長，此時不能讓其餘所有節點一直等待，因為用戶端已經逾時了。是以我們在每個算子内部的執行邏輯中都設定了一些埋點，用以檢查算子的執行是否超過了使用者側的限制時間，一旦超過，便立即終止自身的執行，進而迅速地自我銷毀，避免資源的無謂浪費。
以上就是對一些關鍵設計的介紹。
6. 性能測試
我們在改造工程完成後進行了性能測試，采用 LDBC 組織提供的 SNB 資料集，生成了一個 SF100 級别的社交網絡圖譜，規模達到 3 億頂點，18 億條邊。我們主要考察其一跳、二跳、三跳、四跳等多項查詢性能。
根據評估結果顯示，在一跳和二跳情況下，原生查詢和分布式查詢性能基本相當，未出現負優化現象。從三跳起，分布式查詢相較于原生查詢能實作 50% 至 60% 的性能提升。例如，在 Max degree 場景下的分布式查詢已将時延控制在 50 毫秒以内。在帶有 Max degree 或 Limit 值的情況下，時延均在 200 毫秒以下。盡管資料集與實際業務資料集存在差異，但它們皆屬于社交網絡領域，是以仍具有一定的參考價值。
四跳查詢，無論是原始查詢還是分布式查詢，其時延的規模基本上都在秒至十餘秒的範圍内。因為四跳查詢涉及的資料量實在過于龐大，已達到數十萬甚至百萬級别，僅依賴分布式并行查詢難以滿足需求，是以需要采取其他政策。然而，即便如此，我們所提出的改進方案相較于原始查詢模式仍能實作 50% 至 70% 的提升，效果還是很可觀的。
04
總結與展望
我們結合 MPP 的思想，成功地對原有 REDgraph 的執行流程實作了架構級别上的革新，提出了一種較為通用的圖中分布式并行查詢方案。在完成改良後，至少在業務層面上，原本無法執行的三跳任務現在得以實作，這無疑是一項重大突破。同時，通過實驗驗證，效率得到了 50% 的顯著提升。
随着小紅書 DAU 的持續攀升，業務資料規模正逐漸向着萬億的規模發展。在這樣的大背景下，業務對多條查詢的需求也将日益強烈。是以，該方案本身具有優化的潛力，具備落地的可能性，且有實際應用的場景。是以，我們将繼續緻力于提升 REDgraph 的查詢能力。另外，盡管該方案主要在圖資料庫上實施，但其思想對于其他具有類似重查詢需求的線上存儲系統同樣具有一定的參考價值。是以，其他産品也可借鑒此方案，設計出符合自身需求的高效執行架構。
最後。我們誠摯地邀請對技術有着極緻追求、志同道合的同學們加入我們的團隊。在此，我們特别推薦兩個管道：一是掃描上方二維碼加入微信群，共同探讨圖資料庫相關的技術問題；二是關注小紅書的技術公衆号 REDtech，該公衆号會不定期釋出技術文章，歡迎大家關注和轉發。
05
問答環節
Q：介紹中提到的 LDBC-SF 100 那個資料集選擇測試樣本的規模有多大？另外，分布式方式能夠提升性能，但分布式實施過程中可能會帶來消息通信的成本開支，反而可能導緻測試結果表現不佳，可否介紹一下小紅書的解決方法。
A：三跳基本上都是在幾十萬的量級。
關于分布式引發的消息通信，這确實是一個問題，但在我們的場景下，目前這還不是最嚴重的問題。因為每一跳，特别是三跳中産生的資料量是巨大的，計算算子處理這些資料量所需的時間已經遠遠超過了消息通信的耗時。尤其是在多跳并存的環境中，比如一跳和二跳，其實它們作為中間結果其資料量并不大，一跳隻有幾十上百個，二跳可能也就幾萬個，但是三跳作為最後的需要參與計算的結果直接到了幾十萬，是以通信開銷跟這個比起來，其實是非常微小的。
在消息通信方面，我們也有一些解決思路，比如在發送端開一些很小的視窗（比如 5 毫秒）來做一些聚合，把那些目标點相同的請求進行聚合，這樣可以減少一些通信的請求次數。
以上就是本次分享的内容，謝謝大家。