熱線電話：400-882-3320
痛點
監控場景在變，但底層系統還停留在過去
隨着業務發展，可觀測平台接入的數據不再侷限於基礎監控指標，還包括應用日誌、鏈路、用戶體驗和業務數據。數據規模、查詢併發和保留週期持續增長時，傳統計算與存儲緊耦合的架構容易在擴容效率和資源利用率上遇到瓶頸。
儀表盤、監控器和日常排障中存在大量重複查詢。GuanceDB 3.1 通過專用引擎與流式聚合識別適合加速的查詢模式，減少高頻查詢重複掃描原始數據的開銷，並根據實際負載調度查詢資源。
升級
傳統 MPP 架構 vs GuanceDB 3.1
這是傳統 MPP 架構與 GuanceDB 3.1 架構的對比示意，重點説明存儲與計算解耦後，查詢資源如何根據業務負載獨立調度，在性能、成本和資源隔離之間提供更靈活的選擇。
傳統 MPP 架構
計算與存儲緊耦合，擴展能力有限。計算資源難以動態調整，整體利用率偏低，擴容成本高。
完全存算分離的 AI 時代存儲引擎
採用數據湖倉一體化與存算分離設計，讓數據存儲和查詢計算可以獨立擴展。系統利用雲基礎設施的彈性能力，按業務負載調整查詢資源，並可結合不同算力類型優化資源成本。例如在工作日查詢高峯擴展計算資源，在夜間與週末降低空閒算力。實際容量、查詢併發和彈性範圍以部署規格與服務配額為準。
針對不同企業的需求
通過雙引擎、智能調度、多租戶優化與彈性算力供給等設計，GuanceDB 3.1 實現了可觀測數據處理架構在性能、成本、靈活性上的持續進化，助力企業高效構建更具性價比的數據基礎設施。
系統根據不同企業使用場景，構建了多層次資源調度策略：
01. 高性價比用戶
優先使用共享計算池，並可在高峯時段靈活調用系統中閒置算力，實現資源最大化複用
02. 對性能敏感用戶
配置獨立的查詢計算集羣，確保在任何場景下都具備穩定、快速的響應能力
03. 中小型團隊
統一接入共享池，系統通過併發控制機制，在成本可控的同時保障查詢體驗
04. 以存儲為主的用戶
採用獨立處理路徑，剝離計算資源，進一步降低系統負載和成本
3.1 升級
雙引擎分流，讓每類數據走最合適的路徑
Metric Engine 面向高基數時間序列，Event Engine 面向日誌、鏈路、RUM、安全事件與 AI Agent Events。GuanceDB 3.1 在寫入階段按數據模型分流，再通過 DQL 與 Query Router 提供統一查詢入口。
指標專用引擎
針對時間窗口、長期趨勢與高基數指標優化存儲和查詢路徑
事件專用引擎
統一承載 Logs、Traces、RUM、Events 與 AI Agent Events
統一查詢入口
DQL 與查詢路由按場景調度計算資源，上層使用方式保持一致
3.1 升級
自研倒排索引，讓全文查詢從掃描變成定位
Event Engine 在日誌寫入階段建立詞項到記錄的映射。查詢先從索引定位命中的記錄，再讀取相關數據，避免反覆掃描全部原文，降低全文檢索的計算與存儲放大。
寫入時建立索引
詞項與記錄位置隨數據寫入建立映射，不等待查詢時再掃描
全文查詢先定位
先從索引找到命中範圍，再讀取需要的數據，減少無關計算
融入 Event Engine
與條件過濾、字段檢索和 DQL 查詢共享統一的數據與計算路徑
加速
流式聚合加速引擎
數據寫入的時候，根據用戶的歷史查詢自動構建需要加速的查詢，並按最小的時間分片將數據預聚合，當查詢發現相關數據已經在當前時間範圍內有預聚合結果，直接從流式聚合中獲取數據，而不從原始數據獲取數據了。
透明加速
對適合預聚合的指標與日誌查詢，業務側無需改寫現有儀表盤和監控器，系統自動複用聚合結果
任意數據時間
按數據本身標記的時間進行聚合，並結合寫入與更新機制處理延遲上報數據
資源佔用更低
將適合預聚合的高頻查詢轉由流式聚合結果響應，減少原始數據重複掃描和數據庫查詢壓力
GuanceDB 3.1 的優勢
支持豐富的業務場景
可以為不同的業務提供不同的讀集羣，用於不同的業務場景，使用不同的配置方案（高併發、離線任務等）並且各自隔離
實時查詢
批量報表
業務分析
數據挖掘
GuanceDB 2.0 將為私有化版本繼續提供服務
FAQ
常見問題
GuanceDB 3.1 主要解決什麼問題？
GuanceDB 3.1 解決海量多模態觀測數據的寫入、長期留存、統一查詢和高頻聚合問題，讓 Metrics、Logs、Traces、RUM、Events 與 AI Agent Events 不必分別依賴孤立的數據系統。
Metric Engine 與 Event Engine 有什麼區別？
Metric Engine 面向高基數時間序列，重點處理壓縮、降採樣、長期趨勢和 PromQL 查詢；Event Engine 面向日誌、鏈路、RUM、安全事件和 AI Agent Events，重點處理 Schemaless 明細數據、條件過濾與全文檢索。兩類數據仍通過統一寫入和 DQL 查詢入口使用。
自研倒排索引如何改善日誌全文查詢？
Event Engine 在寫入階段建立詞項到記錄的映射。查詢時先從索引定位命中的記錄，再讀取相關數據，避免每次全文查詢都掃描全部日誌原文，從而減少無關計算和存儲放大。
GuanceDB 為什麼採用存算分離？
存算分離讓存儲和查詢資源可以獨立擴展。團隊可以根據查詢高峯、長期留存和成本要求調整計算資源，而不必把所有數據和計算綁定在同一套集羣裏。
GuanceDB 3.1 如何服務 AI Agent？
GuanceDB 通過 DQL、PromQL 兼容接口和可編程 Pipeline，把多模態觀測數據轉化為可查詢、可關聯的事實層，為 Copilot、Agent Teams 和第三方智能體提供持續更新的生產上下文。