黃東旭：“向量資料庫”還是“向量搜尋外掛 + SQL 資料庫”？

本文由 PingCAP 黃東旭撰寫，討論了資料庫技術在 2023 年的快速變革，並對 2024 年的資料庫發展趨勢進行了預測。文章重點關注了 GenAI 時代對資料庫的影響，提出了在資料庫選擇上的兩種路徑：“向量資料庫”和“向量搜尋外掛 + SQL 資料庫”。文章強調了個性化資料服務的重要性，以及資料庫在實時互動和彈性方面所起到的關鍵作用。

如果我們用一個詞來總結 2023 年的資料技術領域，那個詞無疑是“急速變革”。我們見證了資料庫核心技術與雲原生架構的融合演進，AI+Data 的浪潮湧現，以及使用者工作負載的深刻轉變。GenAI 時代的到來，就像一股不可抗拒的潮流，推動著資料技術的每一朵浪花，朝著更智慧化、更靈活化的巨浪之海奔流。

2023 年，我們的眼前充滿了奪目的 AI Demo 與炫技，你追我趕。轉眼間，當我 們步入 2024 年，這個年份將因為 “AI 在從 Demo 到真實場景落地”的急劇轉變而被人們記住。隨著開源大模型成本的加速下降，企業和開發者對資料的關注也急劇上升，對資料的關注度將很快取代對模型的關注度。有預測認為，在 2023 年，使用者願意在 AI 模型上投入 80% 的預算，然而在未來這一兩年裡，隨著模型成本的降低，這一比重可能會逆轉，使用者將更多的投資（甚至大於 80%）傾向於資料，資料處理和分析能力變得更加重要。

毫無疑問，AI 將會對資料處理提出非常多新的訴求，資料技術領域也會面臨著多重挑戰與機遇，AI 正在重塑資料技術的全新生態。我們不禁要問：在 GenAI 的大潮中，選擇 “向量資料庫”還是“以 SQL 資料庫作為核心，新增向量搜尋外掛”？資料庫如何應對 Gen AI 對資料庫擴充套件性和實時互動的訴求？浪湧般海量資料的實時查詢會不會帶來巨大的成本壓力？AI 帶來的自然互動方式催生怎樣的開發者體驗 ？這些問題將在本文中一一解答

/ 預測一 /

“向量資料庫”還是“向量搜尋外掛 + SQL 資料庫”？這是一個答案很明確的問題。

如果說過去 CRUD 應用是對資料庫訪問的靜態封裝，那麼隨著 GenAI 的普及，尤其是 Chatbot 或 Agent 的產品形態，對資料的使用會是更加靈活和動態的。過去，集中的資料儲存和應用是因為技術的侷限，很難為個人提供個性化的服務，儘管現代的 SaaS 其實很希望往這個方向發展，但是為每個使用者都提供個性化的體驗對算力和開發的挑戰太高，而 GenAI 和 LLM 將提供個性化服務的成本降得很低（可能就是幾段 Prompt），以至於對於資料庫而言，帶來幾個變化：

○ 個人（或一個組織）產生的資料價值會變得越來越高，但這類資料通常不會很大

○ GenAI 會使用更加動態和靈活的方式直接訪問資料，這樣效率最高

○ 對資料的訪問從邊緣發起（從 Agent 或者 GenAI 直接發起）

一個很好的例子是 GPTs， GPTs 支援透過的自定義的 Prompt 和使用者提供的 RESTful API 來建立自己的 ChatGPT，基礎的 ChatGPT 會在它認為需要的時候以靈活的方式呼叫你給定的 Action。這個呼叫發生方式和引數是後端的 Action 提供者無法預料的。而且可以預料的是很快 GPTs 將會提供標記個人身份資訊的機制，這樣對於 Action 的提供者來說，相當於後端的資料庫有了最重要的索引：UserID，剩下的就很好理解了。

這裡你可能會提出質疑，RAG 不是標準的做法嗎？但現有的 RAG 構建的方式幾乎都是靜態的，而知識應該是可以實時被更新的，這裡不得不提到向量資料庫。

對向量的支援，在去年是資料庫迭代的一個熱門方向，產生了很多專門的向量資料庫，  但是我認為，更豐富的資料訪問介面，使得向量搜尋成為標配，然而  SQL  仍然是基石。向量搜尋並不值得專門使用一個獨立的資料庫來支援，更應該是現有的資料庫中的一個功能，就像 ：

Plaintext
Rust   INSERT INTO tbl (user_id, vec, ...) VALUES (xxx, [f32, f32, 
f32 ...], ...);   SELECT * FROM tbl WHERE user_id = xxx and 
vector_search([f32,f32,f32,f32 ...])

類似的訪問可能是更符合開發者直覺的。

而  關係型資料庫天然支援插入和更新 ，另外配合向量索引的搜尋能力，便可以將 RAG 變成一個可以實時更新實時查詢的正反饋迴圈（利用 LLM 引入進行二次的 Summary ，然後將更新的 Index 儲存在 DB 中）。更重要的是，  關係型資料庫的引入消除了向量資料庫帶來的資料孤島的問題 ，當你可以將向量索引篩出來的資料關聯（JOIN）到同一個 DB 中其他的資料的時候，靈活性帶來的價值就得以顯現。

另一個好處是，Serverless 的產品形態，同樣也將資料的所有權歸還給使用者本人，大家思考一下，在我們熟知的 Web2 時代，我們的資料是隱藏在一個個網際網路公司的服務背後的黑箱，我們沒有辦法直接訪問；而在 GenAI 的應用場景下，資料的互動變成一個三角的關係，使用者 - 資料 (RAG) - GenAI。很有意思的是，這個正是 Web3 的理想之一，GenAI 的普及很可能順手也將 Web3 想實現的將資料的所有權交還給使用者的理想，這在 Web2 時代是不可能實現的，這其實是一種技術理想的迴歸。

當然，我相信在未來 RAG 會成為資料庫的很重要的一種新應用場景，在這種場景中 Serverless 形態提供的雲資料庫服務會變成標準化的。

/ 預測二 /

由高價值資料驅動的應用成為 GenAI 應用的主流，彈性與實時互動成為資料庫能力的基石。

在預測一里我們提到， GenAI 時代的應用要求知識和資料是可以被實時更新的，這對資料庫的彈性以及實時互動提出了非常直接的需求。

資料庫的可擴充套件性一直是過去十年間，業界關注的重點之一。根據我們的觀察，大多數單一線上業務，100TB 已經是很大規模，而這個規模下的一般 OLTP 業務，已經可以被市場上很多系統自信的解決。

但這些資料庫大多是 Shared Nothing 的系統，Shared nothing 的系統通常會有一個假設：在叢集中的節點是對等的，只有這樣資料和 Workload 才能均勻的分散在各個節點上。這個假設對於海量資料 + 訪問模式均勻的場景沒有問題，但是仍然  有很多的業務具有明顯的冷熱特徵， 尤其是在 GenAI 帶來的資料訪問方式越來越動態和靈活的 2024 年及以後 。

我們最經常處理的資料庫問題之一就是區域性熱點。如果資料訪問傾斜是一個業務的天然屬性的話，對等的假設就不再是合理的，更合理的方式是將更好的硬體資源傾斜給熱點的資料，而冷資料庫使用更廉價的儲存，例如，TiDB 從一開始將儲存節點（TiKV）/ 計算節點（TiDB）/ 元資訊（PD）分離，以及在後來 TiDB 5.0 中引入自定義 Placement Rule 讓使用者能夠儘可能決定資料擺放策略，就是為了儘可能弱化節點對等假設。

但是更終極的解決辦法在雲端，在基本的擴充套件性問題得到解決後，人們開始追求更高的資源利用效率，在這個階段，對於 OLTP 業務來說，我想可能更好的評價標準是 Cost Per Request。因為在雲端，計算和儲存的成本差別是巨大的，對於冷資料來說，如果沒有 Traffic，你甚至可以認為成本幾乎為 0，但是計算卻是昂貴的，而線上服務不可避免的需要計算（CPU 資源），所以  高效利用計算資源，雲提供彈性將成為關鍵 。

另外，請不要誤解 ，彈性並不意味著便宜，on-demand（ 隨需提供的 ）的資源在雲上通常比 provisioned（預分配）的資源更貴，持續的 burst 一定是不划算的，這種時候使用預留資源更合適，burst 那部分的成本是使用者為不確定性支付的費用。仔細思考這個過程，這可能會是未來雲上資料庫的一種盈利模式，

與彈性同樣重要的需求就是實時互動 。GenAI 時代的應用需要資料庫不僅要有強大的資料處理能力，還需要有高效的實時資料廣播和同步機制。這不只是讓資料能夠實時更新，而是確保資料流能夠實時流動，讓資料庫能即時捕捉到每一次互動，每一個查詢，確保每一個決策都是基於最新、最準確的資訊。（就是使用者願意為更高價值的實時互動付錢，想想股票實時交易和直播電商的場景就知道了）

於是整個系統——從資料的產生到處理、再到儲存和檢索——都必須要在實時的框架下工作，能夠在毫秒級別做出實時響應，這也需要資料庫能實時在事務處理（OLTP）和分析處理（OLAP）之間無縫同步。這樣的實時互動能力，將會是現代資料庫區別於傳統資料庫的決定性因素之一。

/ 預測三 /

成本分析已經成為所有人關心的問題，在雲資料庫的可觀測性中成為獨立新視角。

今天我還想談的一點是雲資料庫的可觀測性，尤其是它是否能讓我的雲消費更透明。對於資料庫雲服務來說，可觀測性的要求會更高，因為對於開發者來說，服務商提供的 Dashboard 幾乎是唯 一的診斷手段。介紹可觀測性的文章也很多，相似的部分因為篇幅關係我也不打算說太多。

與傳統的可觀測性不一樣的是：  在雲上，一切 Workload 都會成為客戶的帳單的一部分 。對於使用者來說一個新的問題便是：為什麼我的帳單看起來是這樣？我需要做什麼才能讓我的帳單更便宜？賬單的可解釋性做得越好，使用者體驗也就越好。

但是如果計費測量的粒度過細，也會影響產品本身的效能以及增加實現的成本。這裡面需要平衡。但可以確定的是，在思考可觀測性產品的方向上，成本分析可以作為一個獨立的新視角。

成本分析可以幫助使用者發現系統執行中的潛在問題，並採取措施予以最佳化。例如，如果使用者觀測到某個資料庫例項的 CPU 使用率較低，但成本卻很高，就可以考慮將該例項的規格調整為更低的級別。

AWS 今年釋出的 Cost and Usage Dashboard 和 Reinvent 上 Amazon CTO Dr. Werner 的演講專注於成本的架構藝術也同樣可以看到這個趨勢。他提出了 “儉約架構” 七大 法則來在雲的環境中打造更加高效、可持續的系統，為我們提供了一個系統性的指導框架。

/ 預測四 /

當 GenAI 時代的各種應用和工具變得越來越輕巧，開發者體驗將成為現代資料庫設計的核心目標之一。

資料庫平臺化不僅僅是漂亮的 Web 管控介面以及一些花哨的功能堆砌。我很喜歡 PlanetScale 的 CEO Sam Lambert 在他的個人 Blog 裡面關 Develop Experience 的描述他引用了賈伯斯的一句話“Great art stretches taste, it doesn’t follow tastes（ 偉大的藝術擴充審美邊界，而不是刻意迎合。）”。

好用的工具之所以好用，是因為其中是飽含了設計者的巧思和品味，而且這個設計者也必須是重度的使用者，這樣人們才能體會到那些細微的快樂與痛苦，但是又不至於沉浸其中使其盲目 ，其實這對負責開發者體驗的產品經理來說是極高的要求。

資料庫管理工具作為一種頻率不算高頻、但每次使用都很嚴肅的工具，在 AI 和雲的時代，我認為有一些與體驗緊密相關的設計原則是需要遵守的：

API First, 資料庫平臺應該提供穩定的 / 前向相容的 API，一切在管控平臺裡能幹的事情，API 都要能做到，最好你的管控平臺是基於你的 API 構造的。這為你提供一個功能齊備的好用的 CLI Tool 也是關鍵的必要條件。

使用統一的認證體系，在設計階段將管控的認證和使用者體系與資料庫內部的認證體系打通，傳統的資料庫基於使用者名稱和密碼的許可權體系在雲的時代是不夠的。這為了後續與雲的 IAM 和 Secret 管理體系對接打下基礎。

對不同的功能構建不同的 / 穩定的小工具 (Do one thing, do things well)，但是透過一個統一的 CLI 入口和語義系統進行呼叫。比較好的例子是 rustup, 甚至 git 也是個很好的例子。

稍微總結一下，2024 年，資料和資料庫技術仍然處於巨大的變革期，誰也沒辦法預測未來，因為我們就身處這麼一個不確定性巨大的時代。但好的一面是，創新仍然層出不窮。我今天預測的，很可能過幾個月就會被我自己全部推翻，也是很正常的事情，如果能給當下的你有所啟發，那就夠了。