全部產品
Search
文件中心

PolarDB:向量檢索

更新時間:Nov 01, 2025

PolarDB MySQL版向量檢索將向量相似性搜尋能力深度整合於資料庫核心。在儲存和處理結構化資料的同時,可對文本、圖片、音頻等非結構化資料產生的向量進行高效的相似性檢索。您無需搭建和維護獨立的向量資料庫及複雜的資料同步鏈路,即可在PolarDB叢集內構建AI應用,如語義搜尋、智能推薦、以圖搜圖等。PolarDB提供兩種向量檢索協議,以適應不同技術棧和業務情境:完全相容MySQL協議,以及相容主流搜尋生態的OpenSearch協議(PolarSearch)。

核心概念

  • 向量嵌入 (Vector Embedding) :一種將現實世界中的非結構化資料(如文本、映像)通過預訓練的嵌入模型轉換為數值數組(即向量)的技術。這些向量能夠捕捉資料的深層語義資訊,使得機器可以理解和比較它們的相似性。

  • 相似性搜尋(k-NN):即k-最近鄰搜尋。其核心目標是在海量向量資料中,找到與給定查詢向量“距離”最近的k個向量。這裡的“距離”可以通過不同的數學公式計算,代表了資料在語義上的相似程度。

  • 向量索引:為了避免在海量資料中進行逐一的全量比對,需要預先建立向量索引。索引是一種為高效查詢而最佳化的資料結構,它能根據向量的分布特徵,在查詢時快速縮小搜尋範圍,從而在保證召回率的同時,將檢索延遲從秒級降低到毫秒級。

  • 向量索引演算法對比PolarDB支援多種業界主流的向量索引演算法,其中HNSW和IVF是最常用的兩種,它們在效能、資源消耗和適用情境上各有側重。

    • HNSW(Hierarchical Navigable Small World):一種基於圖的索引,具有高效能和高召回率的優點,但記憶體開銷也相應較大。適用於對查詢延遲和精度要求極高,且資料集大小在記憶體容量範圍內的情境。

    • IVF(Inverted File):一種基於聚類的倒排索引,記憶體佔用較低,更適合需要處理超大規模資料集且記憶體受限的情境,但其搜尋精度通常略低於HNSW。

功能優勢

PolarDB向量檢索引擎將關係型資料庫的易用性與專用向量資料庫的高效能融為一體,與其他技術選型相比,具備顯著優勢。

特性

傳統關係型資料庫

專用向量資料庫

PolarDB向量檢索引擎

SQL支援

支援

不支援

支援

向量檢索

效能差

高效能

高效能

學習成本

生態相容

豐富

有限

雙生態

擴充性

有限

良好

優秀

營運複雜度

簡單

複雜

簡單

除此之外,它還具備以下核心優勢:

  • 一站式解決方案:無需引入獨立的向量資料庫,在PolarDB中即可同時處理業務資料和向量資料,有效簡化系統架構,降低營運成本。

  • 企業級可靠性:全面支援ACID事務,保障資料一致性。分布式架構支援高可用和故障自動切換,確保商務持續性。

  • 與LLM緊密整合:內建了通義千問大模型的推理能力,簡化了AI應用的開發鏈路。

核心能力與效能指標

檢索效能

  • 延遲:P99(99%請求) < 10ms,P95(95%請求) < 5ms。

  • 輸送量:單節點 > 10,000 QPS。

  • 精度:召回率 > 99%。

擴充能力

  • 資料規模:支援PB級向量資料,可支撐數十億級向量檢索。

  • 並發能力:支援數萬並發查詢。

  • 叢集規模:支援動態擴容至數百個節點,具備智能資料分區策略。

資源效率

  • 儲存壓縮:向量資料壓縮率 > 50%。

  • 記憶體使用量:通過分層緩衝技術,有效支援TB級圖索引。

  • CPU利用率:通過多核並行最佳化,CPU利用率 > 80%。

應用情境

PolarDB提供雙協議設計。您可根據團隊技術棧、業務需求和效能預期,選擇合適的協議。

對比維度

MySQL協議

OpenSearch協議

訪問方式

標準SQL

RESTful API (相容Elasticsearch/OpenSearch)

核心優勢

與業務Data Integration:支援對現有表添加向量列、支援ACID事務,學習成本低。

混合檢索能力:支援向量、全文、標量等組合查詢,生態成熟。

底層依賴

依賴列存索引(IMCI)。向量檢索在列存索引唯讀節點上執行,實現分析與事務負載隔離。

運行在獨立的搜尋節點(PolarSearch)上,提供類似搜尋引擎的服務。

資料同步

無需同步。資料寫入主庫後,對列存索引唯讀節點自動可見。

無需同步。資料寫入主庫後,對搜尋節點自動可見。

智能問答與客服機器人

  • 業務痛點:傳統的關鍵詞匹配無法理解使用者問題的真實意圖,導致答案不準確。

  • 解決方案:將知識庫中的“問題-答案”對轉換為向量儲存。當使用者提問時,將其問題同樣轉換為向量,通過相似性搜尋找到最匹配的幾個知識點,從而提供更精準的回答。

  • 協議推薦

    • MySQL協議:如果僅需實現基礎的語義匹配,且希望在現有MySQL應用中快速整合,此方案更便捷。

    • OpenSearch協議:如果需要結合關鍵詞、分類標籤等進行複雜篩選,推薦使用其混合搜尋能力。

個人化推薦系統

  • 業務痛點:如何根據使用者的歷史行為(瀏覽、點擊、購買)推薦其可能感興趣的商品或內容。

  • 解決方案:將使用者和物品(商品、文章、視頻)都表示為向量。通過計算使用者向量與物品向量的相似性,可以召回一批使用者可能感興趣的候選集,再結合其他策略進行精排。

  • 協議推薦

    • OpenSearch協議:推薦系統的召回層通常資料量巨大,且對效能和成本敏感。OpenSearch協議提供的IVF索引和PQ量化技術適用於應對海量資料和控制記憶體成本的情境。

以圖搜圖與多模態檢索

  • 業務痛點:如何通過上傳一張圖片來尋找相似的圖片,或者通過文字描述來尋找圖片。

  • 解決方案:將圖片和文本都轉換為向量,並儲存在PolarDB中。無論是輸入圖片還是文本,都將其轉換為查詢向量,在資料庫中進行相似性搜尋。

  • 協議推薦

    • MySQL協議:對於需要將圖片特徵向量與商品ID、價格等業務資料進行強一致性管理的情境,MySQL協議的事務能力是重要保障。

常見問題

PolarDB向量引擎與獨立的向量資料庫(如Milvus)相比有什麼優勢?

主要優勢在於一體化和低成本。

  • 無需資料同步:向量資料與業務資料存放區在同一系統內,避免了傳統“MySQL + 向量資料庫”架構中複雜的資料同步鏈路。

  • 簡化技術棧:減少了一套獨立的資料庫系統,降低了開發、營運、學習的複雜度和總體擁有成本(TCO)。

  • 事務一致性:使用MySQL協議時,向量操作與商務資料執行可在同一事務中完成,保證資料的一致性。

使用MySQL協議進行向量檢索為什麼需要列存索引唯讀節點?

為了實現負載隔離和效能最佳化。向量檢索屬於計算密集型的分析類查詢(AP),而資料庫主節點通常承載線上交易(OLTP)負載。

  • 將向量檢索放在列存索引唯讀節點上,可利用列式儲存和並行計算的優勢加速查詢。

  • 該架構將分析負載與交易負載物理隔離,避免向量查詢影響核心業務的穩定性和回應時間。