在之前的產品篇，我們瞭解到了 NebulaGraph 內核及周邊工具在 2023 年經歷了什麼樣的變化。伴隨着這些特性的變更和上線，在【文章】博客分類中，一篇篇的博文記錄下了這些功能背後的設計思考和研發實踐。當中，既有對內存管理 Memory Tracker 的原理講解，也有對 NebulaGraph 的安裝選擇指引。
而 LLM 作爲 2023 年技術圈的一大熱點，NebulaGraph 也憑藉 Graph + RAG 的契機，讓社區用戶瞭解到了在圖、知識圖譜、大模型這一新的三元組。無獨有偶，社區小夥伴 @heikeladi 的《利用 ChatGLM 構建知識圖譜》也開啓了 GPT 構建知識圖譜的新章節，讓知識圖譜的構建更加 easy。
不只是 LLM、圖數據庫 NebulaGraph，今年也是 DDIA（design data-intensive application）系列在 NebulaGraph 技術社區連載的第一年，從底層數據結構到頂層架構設計，帶你更全面地瞭解分佈式系統。
下面，來看看今年 NebulaGraph 技術社區有哪些博文值得你讀一讀。如果你覺得某篇文章不錯，不要吝嗇你的 ❤︎，你的評論和點贊是對作者們最好的讚賞 ❤︎。
LLM + GRAPH
自 2023.05，Wey 在 LlamaIndex 的 pr#2581 中第一次將圖數據庫、知識圖譜和 LLM 放在一起，從此揭開了 Graph + RAG 的面紗。
利用 ChatGLM 構建知識圖譜
這是一名東方財富算法工程師陳卓見的大模型實踐，在經歷 1.0 時代，會利用大量的規則和人力去提取和校驗相應的數據，到 2.0 時代去構建相應的深度學習模型輔助完成 NER、實體鏈接，到現在大模型時代，利用大模型去清晰數據、標註和訓練數據。本文給出了這位工程師的 Demo 分享；
LLM + NebulaGraph 三部曲
在 《圖技術在 LLM 下的應用：知識圖譜驅動的大語言模型 Llama Index》 中，Wey 詳細地講解了何爲 LLM 範式，Llama Index 是如何同模型交互的，以及在 Embedding 和向量對搜索結果效果不佳的情況下，知識圖譜是如何輔助增加搜索結果的。
作爲上篇，它講述了知識圖譜同 LLM 的關係。在隨後的《Text2Cypher：大語言模型驅動的圖查詢生成》和《Graph RAG: 知識圖譜結合 LLM 的檢索增強》，分別講述了自然語言到查詢語言的轉化：
- 將任務拆解成從自然語言中理解意圖
- 找出實體
- 從意圖和實體構造查詢語句
以及 Graph RAG 與 Vector RAG 的結果對比，相比單獨的向量搜索，有了知識圖譜的 RAG 會更加精準。
向量檢索 vs 關鍵詞檢索 vs 混合檢索怎麼選？
基於 Wey 在 Llama Index 以及 LangChain 的 Graph + RAG 貢獻，海外工程師 Wenqi Glantz 對所有 Graph + LLM、RAG 方法進行了全面的實驗、評估、綜述、總結和分析。《7 種查詢策略教你用好 Llama Index 和 NebulaGraph 探索知識圖譜》 便是本次實驗測評的中文譯文：
哪個查詢引擎最適合，將取決於你的特定使用情況。
- 如果你的數據源中的知識片段是分散和細粒度的，並且你需要對你的數據源進行復雜的推理，如提取實體和它們在網格中的關係，如在欺詐檢測、社交網絡、供應鏈管理，那麼知識圖譜查詢引擎是一個更好的選擇。當你的 Embedding 生成假相關性，導致幻覺時，KG 查詢引擎也很有幫助。
- 如果你需要相似性搜索，如找到所有與給定節點相似的節點，或找到在向量空間中最接近給定節點的所有節點，那麼向量查詢引擎可能是你的最佳選擇；
- 如果你需要一個能快速響應的查詢引擎，那麼向量查詢引擎可能是一個更好的選擇，因爲它們通常比 KG 查詢引擎更快。即使沒有 Embedding，任務的提取（運行在 NebulaGraph 單個 storage 服務上的子任務）也可能是 KG 查詢引擎延遲高的主要原因；
- 如果你需要高質量的回答，那麼自定義組合查詢引擎，它結合了 KG 查詢引擎和向量查詢引擎的優勢，是你最好的選擇。
新手友好
使用 NebulaGraph 的第一步便是安裝部署，如何提供保姆級的安裝教程，讓新用戶 Step By Step 按照教程完成一開始的部署安裝呢？想必沒有比 @墮落飛鳥 更合適回答這個問題的人了。
用上 NebulaGraph
在 NebulaGraph 技術社區年度徵文活動中，飛鳥以一己之力更新了 5 篇極度新手友好的部署安裝相關文章：
《NebulaGraph 安裝方式選擇》中不只是給出了 7 種安裝方式：編譯、Docker 編譯、單機部署、集羣部署、Docker-Compose 安裝、K8s 安裝和 Docker 集羣部署，還給出了這 7 種方式的優劣。下圖僅供參考：
| 編譯安裝 | Docker 編譯安裝 | 單機安裝 | 集羣安裝 | Docker-Compose 安裝 | K8s 安裝 | Docker 集羣 | |
|---|---|---|---|---|---|---|---|
| 部署維護難度 | ★★ | ★★ | ★ | ★★★ | ★★ | ★★★ | ★★ |
| 所需資源 | ★ | ★ | ★ | ★★★ | ★★ | ★★★ | ★★★ |
| 高可用，高性能 | ★ | ★ | ★ | ★★★ | ★★ | ★★★ | ★★★ |
而隨後飛鳥更新的 《NebulaGraph 的備份管理》 則詳細地記錄了使用備份工具 BR 的過程。不同於 Linux 之類的本地環境，容器化部署的備份方式也是部分社區小夥伴關心的話題。《NebulaGraph 使用 Docker-Compose 部署方式如何備份還原》 便是一個詳細到沒朋友的容器化部署備份文。
無獨有偶，《使用 RKE 方式搭建 K8s 集羣並部署 NebulaGraph》 則從 K8s 入手，用一文留下了他是如何使用 RKE 來搭建 NebulaGraph 的過程。《構建 Nebula Graph 3.3.0 和 Nebula Studio 3.7.0 在 ARM 架構上的指南》 則爲 ARM 用戶帶來了一絲暖意，無痛地在 ARM 上用上 NebulaGraph 和 NebulaGraph Studio。
等你有了良好的 NebulaGraph 運行環境，下面就可以試試《使用 NebulaGraph Exchange 通過 Hadoop 導入 OwnThink 數據》，領略一下千億知識圖譜 OwnThink 導入 NebulaGraph 的全過程，以及用這個知識圖譜搭建你自己的智能機器人。而《可視化探討 NebulaGraph 開源社區中的貢獻關係》在提供數據集的基礎之上，手把手教你如何用可視化探索工具進行導數、查詢，觀察到數據之間的關係。
上面講到的用上 NebulaGraph 的 case 都是從零到一，搭建一個空的圖數據庫，但是如果你已經擁有了成百億上千億的數據，如何無縫切換到 NebulaGraph 模式呢？《圖數據庫系統重構之路》 給那些時間緊、對已有技術棧不了的社區小夥伴指明瞭方向，重構應該這樣做：
- 對外接口梳理：梳理系統所有對外接口，包括接口名、接口用途、請求量 QPS、平均耗時，調用方（服務和 IP）；
- 老系統核心流程梳理：輸出老系統整理架構圖，重要的接口（大概 10 個）輸出流程圖；
- 環境梳理：涉及到的需要改造的項目有哪些，應用部署、MySQL、Redis、HBase 集羣 IP，及目前線上部署分支整理；
- 觸發場景：接口都是如何觸發的，從業務使用場景出發，每個接口至少一個場景覆蓋到，方便後期功能驗證；
- 改造方案：可行性分析，針對每一個接口，如何改造（OrientDB 語句改爲 NebulaGraph 查詢語句），入圖（寫流程）如何改造；
- 新系統設計方案: 輸出整理架構圖，核心流程圖。
用好 NebulaGraph
當你有了良好的運行環境，面臨的就是如何將你的業務 NebulaGraph 化的問題。也許你是從 MySQL 之類關係型數據庫來一探圖數據庫的奇妙，也許你是從 Neo4j、JanusGraph 來想看看 NebulaGraph 的高性能。這時候有一份貼心的進階使用指南，就非常完美了。
說到進階用法，有什麼比同廣大用戶頻繁交流，獲得他們使用姿勢，進而總結出的一份產品最佳實踐更合適的呢？《使用祕籍｜如何實現圖數據庫 NebulaGraph 的高效建模、快速導入、性能優化》 由 NebulaGraph 產品總監出品，它收錄了從圖建模開始的各類優化指南，沒想到你的 VID 大小也和性能息息相關，更別提多塊硬盤竟然能左右寫速率。文中收錄了各種獲取高性能的技巧，如果是新手的話，讀一讀必有收穫。
除了產品的最佳實踐，NebulaGraph 的資深研發和佈道師也從執行計劃角度，讓大家瞭解查詢語句生命週期之餘，讀明白那些執行算子的作用，以及語句執行的耗時點在何處：
說完官方出品的使用指北，再來看看其他小夥伴是咋用好 NebulaGraph 的。在今年開啓的 Happy Office Hour 便是一個官方對話用戶的活動，在活動中 NebulaGraph 的資深用戶會和大家交流他們的使用姿勢，而相關的會議紀要你將瞭解到更多的 NebulaGraph 實用技能。正如第一期會議紀要《如何提升 meta 性能？提高 TTL 刪除速率？主備集羣怎麼做…Happy Office Hour 第一期會議紀要告訴你》 所記錄的那樣，你可以瞭解到大企業他們面臨的業務問題，以及如何更好地解決、規避這個問題。
內存管控
資源的使用，尤其是內存的使用，是社區用戶關心的一大重點。而到底 NebulaGraph 有哪些地方需要使用內存？這是 @肖小可愛樂樂 在文章《NebulaGraph 的內存探查》 中所要探討的主題。
NebulaGraph 內存初探
一般來說數據庫會在多個方面使用到內存，比如：線程池、緩衝區、索引等等。在《NebulaGraph 的內存探查》 中，作者先從一般數據庫的內存消耗點講起，再娓娓道來 NebulaGraph 的工作流程，最後通過實驗數據查看在數據導入之後，nebula-storage 的內存使用量變化。
雖然文章並未提及到查詢時內存的消耗情況，但是通過本文你將瞭解一些 nebula-storage 存儲方面的內存使用點。下面摘錄了部分結論：
- 面對重複插入的數據，nebula 採用忽略掉的機制。假使數據長度不符合不能寫入 nebula-storage，將會都寫入 nebula-storage 的 err 日誌上，不會佔用內存。
- 當 CPU 個數較少，Compact 落盤釋放內存資源的速度慢於寫入數據的速度，內存會持續上升。
- 讀操作統計 Tag 和 Edge 個數，假設個數太多將耗費 nebula-storage 大量的內存，如果 nebula-storage 有寫入操作，很容易令 nebula 進入崩潰狀態。
如果你想了解 nebula-storage 這塊的內存消耗，不妨讀一讀此文參考下。此外，在《NebulaGraph 內存分析》 中，淺析了下三大服務——metad、graphd、storaged 的內存消耗點，可作爲理論輸入，再結合你具體的業務場景再探內存用量。
Memory Tracker
數據庫的內存管理是數據庫內核設計中的重要模塊，內存的可度量、可管控是數據庫穩定性的重要保障。圖數據庫的多度關聯查詢特性，往往使圖數據庫執行層對內存的需求量巨大。
《內存管理實踐之 Memory Tracker》主要介紹 NebulaGraph v3.4 版本中引入的新特性 Memory Tracker，希望通過 Memory Tracker 模塊的引入，實現細粒度的內存使用量管控，降低 graphd 和 storaged 發生被系統 OOM kill 的風險，提升 NebulaGraph 圖數據庫的內核穩定性。
另類實踐
大多數的用戶都是使用官方提供的周邊工具，例如：nebula-java 客戶端來操作圖數據，而 auhusy 則對 nebula-python 在《python 簡單封裝CRUD》進行了封裝，CurvusY 用 Dart 對 NebulaGraph 進行了移動端適配，開發出來了nebula_dart_gdbc，在手機端也可能查詢圖數據，《使用 GraphQL 語法查詢 NebulaGraph 中的數據》則記下了 Dragonchu 對 GraphQL 的適配，讓前端自由地選擇想要的數據。
聊聊數據庫和分佈式
除了 NebulaGraph 使用相關的文章之外，本年度還有同分布式系統相關的 DDIA 系列，以及 RocksDB 的講解文。
DDIA 系列由數據庫研發人員從自身的開發經驗出發，結合原書傳授的數據系統的設計理念，深入淺出地道明數據系統中的精妙之處。
《一文科普 RocksDB 工作原理》 全方位講解 kv 嵌入數據庫 RocksDB 的核心概念 LSM-Tree、MemTable 和 SSTables，《RocksDB Iterator Internal, part 1》 從工程師角度，以源碼閱讀的形式帶你深入瞭解 RocksDB 的組件。
2023 年的文章介紹告一段落，感謝你的閱讀 (///▽///) 。你可以前往論壇-文章區，閱讀本年度所有的文章。
如果你有什麼想看，但是社區並沒有安排上，來和星雲小姐姐 說道說道。