https://yennj12.js.org/yennj12_blog_V4/tags/rdbms/Recent content in RDBMS on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 29 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part3-comparison-zh/Mon, 29 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part3-comparison-zh/大多數人問「知識圖譜會不會取代資料庫？」 正確答案是：問錯問題了。它們解決的是不同維度的問題。 大多數人看到向量資料庫很紅，就以為知識圖譜過時了。 正確答案是：在 LLM 時代，兩者反而是最佳拍檔（Part 4 詳述）。 接續前文 Part 1 講概念、Part 2 動手建。這一篇要把知識圖譜放到擂台上，和四種常見的資料儲存技術正面比較，幫你建立清楚的選型判斷力。 一、核心問題：四種技術在解什麼問題？ 先用一句話定位每種技術的「世界觀」： ┌──────────────────┬──────────────────────────────────────────────┐ │ 關聯式 (RDBMS) │ 「我有結構化的表格，要保證交易一致性」 │ │ 文件 (Document) │ 「我有半結構化的 JSON，schema 常變」 │ │ 向量 (Vector DB) │ 「我要找『意思相近』的東西（語意相似）」 │ │ 知識圖譜 (KG) │ 「我要表達並推理『實體之間的關係』」 │ └──────────────────┴──────────────────────────────────────────────┘ 關鍵洞察：它們優化的維度不同。RDBMS 優化交易一致性、文件庫優化 schema 彈性、向量庫優化語意相似、知識圖譜優化關係推理。問「誰取代誰」是問錯了；該問的是「我這個問題的本質是哪一種」。 二、知識圖譜 vs 關聯式資料庫（RDBMS） 這是最常被拿來比的一組。差異的核心在於：關係是如何被表示的。 面向 知識圖譜 關聯式資料庫 關係表示 一等公民，直接存在邊上 靠 foreign key + JOIN 隱式重建 多跳查詢 圖遍歷，效能與跳數弱相關 多重 JOIN，跳數越多越慢 Schema 彈性 高，加關係不需 migration 低，改表結構成本高 交易一致性 多數圖庫較弱（部分支援 ACID） 強項，成熟的 ACID 聚合運算 較弱 強（SUM/GROUP BY 等） 成熟度/生態 相對年輕 數十年積累、人人會 SQL 為什麼選知識圖譜不選 RDBMS：當你的查詢核心是「關係的關係」—— 多跳路徑、最短路徑、社群偵測、影響力傳播。例如風控要查「這筆交易的對手方，透過幾層人頭帳戶連到黑名單」。