Postgres 繼續(xù)推動數(shù)據(jù)庫格局的發(fā)展，超越傳統(tǒng)的關(guān)系數(shù)據(jù)庫用例。其豐富的擴展和派生解決方案生態(tài)系統(tǒng)使 Postgres 成為一股強大的力量，尤其是在時間序列和地理空間等領(lǐng)域，以及最近的生成式 AI 工作負載。

Pgvector已成為希望使用 Postgres 作為矢量數(shù)據(jù)庫的新一代 AI 應用的基礎(chǔ)擴展。簡而言之，pgvector 添加了新的數(shù)據(jù)類型、運算符和索引類型，以處理 Postgres 中的矢量化數(shù)據(jù)(嵌入)。這允許您使用數(shù)據(jù)庫對嵌入進行相似性搜索。

Pgvector 在 2023 年開始騰飛，GitHub 星星數(shù)量激增：

純向量數(shù)據(jù)庫，例如 Pinecone，不得不承認 pgvector 的存在并開始發(fā)布競爭性材料。我認為這對 Postgres 來說是一個好兆頭。

為什么這是個好兆頭?正如我的 Postgres 社區(qū)成員Rob Treat 所說，“一開始他們會忽略你。然后他們會嘲笑你。然后他們會創(chuàng)建基準測試。最后你就贏了!”

那么，這與分布式 Postgres 主題有何關(guān)系?

Postgres 用于新一代 AI 工作負載的頻率越高，你就會越頻繁地聽到(來自其他解決方案背后的供應商)基于 Postgres 構(gòu)建的新一代 AI 應用程序?qū)⒕哂幸韵绿攸c：

可擴展性和性能問題

數(shù)據(jù)隱私面臨的挑戰(zhàn)

高可用性的艱難時期

如果確實遇到了列出的問題，則不應立即放棄 Postgres 并遷移到更具可擴展性、高度可用、安全的矢量數(shù)據(jù)庫，至少在您嘗試在分布式配置中運行 Postgres 之前不要這樣做!

讓我們討論何時以及如何使用分布式 Postgres 來處理 gen AI 工作負載。

什么是分布式 Postgres?

Postgres 專為單服務(wù)器部署而設(shè)計。這意味著單個主實例存儲所有應用程序數(shù)據(jù)的一致副本并處理讀取和寫入請求。

如何讓單服務(wù)器數(shù)據(jù)庫分布式?您可以利用 Postgres 生態(tài)系統(tǒng)!

在 Postgres 生態(tài)系統(tǒng)中，人們通常對分布式 Postgres 做出以下假設(shè)之一：

具有多主異步復制和沖突解決功能的多個獨立 PostgreSQL 實例(如 EDB Postgres Distributed)

與協(xié)調(diào)器 (如 CitusData) 一起分片的 Postgres

無共享的分布式 Postgres(如 YugabyteDB)

有關(guān)每個部署選項的更多信息，請查看以下指南。至于本文，讓我們研究何時以及如何將分布式 Postgres 用于您的 gen AI 工作負載。

問題 1：嵌入使用所有可用的內(nèi)存和存儲空間

如果您曾經(jīng)使用過將文本、圖像或其他類型的數(shù)據(jù)轉(zhuǎn)換為矢量化表示的嵌入模型，您可能已經(jīng)注意到生成的嵌入是相當大的浮點數(shù)數(shù)組。

例如，您可以使用 OpenAI 嵌入模型將文本值轉(zhuǎn)換為 1536 維浮點數(shù)數(shù)組。考慮到數(shù)組中的每個項目都是 4 字節(jié)浮點數(shù)，單個嵌入的大小約為 6KB — 這是相當大數(shù)量的數(shù)據(jù)。

現(xiàn)在，如果您有 1000 萬條記錄，則僅這些嵌入就需要分配大約 57 GB 的存儲空間和內(nèi)存。此外，您還需要考慮索引(例如 HNSW、IVFFlat 等)占用的空間，許多人會創(chuàng)建這些索引來加快向量相似性搜索。

總體而言，嵌入的數(shù)量越多，Postgres 需要的內(nèi)存和存儲空間就越多，以有效地存儲和管理它們。

您可以通過切換到生成維度較少的向量的嵌入模型或使用量化技術(shù)來減少存儲和內(nèi)存使用量。但是，假設(shè)我需要這些 1536 維向量，并且我不想應用任何量化技術(shù)。在這種情況下，如果嵌入的數(shù)量繼續(xù)增加，我的數(shù)據(jù)庫實例的內(nèi)存和存儲容量可能會超出承受范圍。

這是一個可以利用分布式 Postgres 的明顯領(lǐng)域。例如，通過運行分片版本 (CitusData) 或無共享版本 (YugabyteDB) 的 PostgreSQL，您可以讓數(shù)據(jù)庫在整個節(jié)點集群中均勻分布您的嵌入。

使用這種方法，您不再受單個節(jié)點的內(nèi)存和存儲容量的限制。如果您的應用程序繼續(xù)生成更多嵌入，您可以隨時通過添加更多節(jié)點來擴展集群。

問題 2：相似性搜索是一項計算密集型操作

這個問題與上一個問題密切相關(guān)，但重點是 CPU 和 GPU 的利用率。

當我們說“只需對存儲在數(shù)據(jù)庫中的嵌入執(zhí)行向量相似性搜索”時，這項任務(wù)對我們?nèi)祟悂碚f聽起來很簡單明了。然而，從數(shù)據(jù)庫服務(wù)器的角度來看，這是一項計算密集型操作，需要大量的 CPU 周期。

例如，這是用于計算兩個向量之間余弦相似度的公式。我們通常使用余弦相似度來查找給定用戶提示的最相關(guān)數(shù)據(jù)。

想象一下，A是新提供的用戶提示的向量或嵌入，B是存儲在 Postgres 中的獨特業(yè)務(wù)數(shù)據(jù)的向量或嵌入。如果您從事醫(yī)療保健行業(yè)，B可能是特定疾病的藥物和治療方法的矢量化表示。

為了找到與所提供用戶癥狀(向量 A)最相關(guān)的治療方法(向量 B)，數(shù)據(jù)庫必須計算A和B的每個組合的點積和幅度。對比較嵌入中的每個維度(公式中的“i”)重復此過程。如果您的數(shù)據(jù)庫包含一百萬個 1536 維向量(治療方法和藥物)，Postgres 必須針對每個用戶提示對這些多維向量執(zhí)行一百萬次計算。

近似最近鄰搜索 (ANN) 允許我們通過為矢量化數(shù)據(jù)創(chuàng)建專用索引來減少 CPU 和 GPU 的使用。但是，使用 ANN 會犧牲一些準確性;由于數(shù)據(jù)庫不會比較所有矢量，您可能無法始終獲得最相關(guān)的治療或藥物。此外，這些索引也有成本：它們需要時間來構(gòu)建和維護，并且需要專用的內(nèi)存和存儲空間。

如果您不想受到單個數(shù)據(jù)庫服務(wù)器的 CPU 和 GPU 資源的限制，可以考慮使用分布式版本的 Postgres。每當計算資源成為瓶頸時，您都可以通過添加新節(jié)點來擴展數(shù)據(jù)庫集群。一旦新節(jié)點加入集群，像YugabyteDB這樣的分布式數(shù)據(jù)庫就會自動重新平衡嵌入并立即開始利用新節(jié)點的資源。

問題3：數(shù)據(jù)隱私

每當我演示 LLM 和 Postgres 的組合可以實現(xiàn)什么時，開發(fā)人員都會受到啟發(fā)。他們會立即嘗試將這些 AI 功能匹配并應用到他們開發(fā)的應用程序上。

然而，總是有一個與數(shù)據(jù)隱私相關(guān)的后續(xù)問題：“如何在不損害數(shù)據(jù)隱私的情況下利用 LLM 和嵌入模型?”答案有兩個方面。

首先，如果您不信任特定的 LLM 或嵌入模型提供商，您可以選擇使用私有或開源模型。例如，使用 Mistral、LLaMA 或 Hugging Face 的其他模型，您可以從自己的數(shù)據(jù)中心或云環(huán)境中安裝和運行這些模型。

其次，一些應用程序需要遵守數(shù)據(jù)駐留要求，以確保私有 LLM 和嵌入模型使用或生成的所有數(shù)據(jù)永遠不會離開特定位置(數(shù)據(jù)中心、云區(qū)域或區(qū)域)。

在這種情況下，您可以運行多個獨立的 Postgres 實例，每個實例都使用來自特定位置的數(shù)據(jù)，并允許應用程序?qū)訁f(xié)調(diào)跨多個數(shù)據(jù)庫服務(wù)器的訪問。

另一種選擇是使用分布式 Postgres 部署的地理分區(qū)功能，它可以自動在多個位置分發(fā)和訪問數(shù)據(jù)，從而簡化應用程序邏輯。

讓我們繼續(xù)討論醫(yī)療保健用例，看看地理分區(qū)如何讓我們能夠根據(jù)數(shù)據(jù)監(jiān)管機構(gòu)的要求跨地區(qū)分發(fā)有關(guān)藥物和治療的信息。在這里，我使用 YugabyteDB 作為分布式 Postgres 部署的示例。

假設(shè)有三家醫(yī)院，一家在舊金山，另外兩家分別在芝加哥和紐約。我們部署一個分布式 YugabyteDB 集群，每個醫(yī)院附近的區(qū)域(或私有數(shù)據(jù)中心)都有多個節(jié)點。

為了遵守數(shù)據(jù)隱私和監(jiān)管要求，我們必須確保這些醫(yī)院的醫(yī)療數(shù)據(jù)永遠不會離開各自的數(shù)據(jù)中心。

通過地理分區(qū)，我們可以實現(xiàn)如下目標：

創(chuàng)建 Postgres 表空間并將其映射到美國西部、中部和東部的云區(qū)域。每個區(qū)域至少有一個 YugabyteDB 節(jié)點。

SQL

CREATE TABLESPACE usa_east_ts WITH (

replica_placement = '{"num_replicas": 1, "placement_blocks":

[{"cloud":"gcp","region":"us-east4","zone":"us-east4-a","min_num_replicas":1}]}'

);

CREATE TABLESPACE usa_central_ts WITH (

replica_placement = '{"num_replicas": 1, "placement_blocks":

[{"cloud":"gcp","region":"us-central1","zone":"us-central1-a","min_num_replicas":1}]}'

);

CREATE TABLESPACE usa_west_ts WITH (

replica_placement = '{"num_replicas": 1, "placement_blocks":

[{"cloud":"gcp","region":"us-west1","zone":"us-west1-a","min_num_replicas":1}]}'

);

創(chuàng)建一個治療表，用于保存有關(guān)治療和藥物的信息。每種治療方法都有一個關(guān)聯(lián)的多維向量——description_vector該向量是使用嵌入模型為治療描述生成的。最后，該表按列進行分區(qū)hospital_location。

SQL

CREATE TABLE treatment (

id int,

name text,

description text,

description_vector vector(1536),

hospital_location text NOT NULL

)

PARTITION BY LIST (hospital_location);

分區(qū)定義如下，例如hospital3舊金山的 數(shù)據(jù)會自動映射到usa_west_ts美國西部數(shù)據(jù)庫節(jié)點的 。

SQL

CREATE TABLE treatments_hospital1 PARTITION OF treatment(id, name, description, description_vector, PRIMARY KEY (id, hospital_location))

FOR VALUES IN ('New York') TABLESPACE usa_east_ts;

CREATE TABLE treatments_hospital2 PARTITION OF treatment(id, name, description, description_vector, PRIMARY KEY (id, hospital_location))

FOR VALUES IN ('Chicago') TABLESPACE usa_central_ts;

CREATE TABLE treatments_hospital3 PARTITION OF treatment(id, name, description, description_vector, PRIMARY KEY (id, hospital_location))

FOR VALUES IN ('San Francisco') TABLESPACE usa_west_ts;

部署地理分區(qū)數(shù)據(jù)庫集群并定義所需的表空間和分區(qū)后，讓應用程序連接到它并允許 LLM 訪問數(shù)據(jù)。例如，LLM 可以使用以下命令直接查詢治療表：

SQL

select name, description from treatment where

1 - (description_vector ? $user_prompt_vector) > 0.8

and hospital_location = $location

分布式 Postgres 數(shù)據(jù)庫會自動將請求路由到存儲指定 數(shù)據(jù)的節(jié)點hospital_location。這同樣適用于INSERTs 和UPDATEs;對治療表的更改將始終存儲在屬于該醫(yī)院位置的分區(qū)->表空間->節(jié)點中。這些更改永遠不會復制到其他位置。

問題#4：高可用性

盡管 Postgres 被設(shè)計為在單服務(wù)器配置中運行，但這并不意味著它不能在高可用性設(shè)置中運行。根據(jù)您所需的恢復點目標 (RPO) 和恢復時間目標 (RTO)，有幾種選擇。

那么，分布式 Postgres 有什么用呢?借助分布式 PostgreSQL，您的 gen AI 應用程序即使在區(qū)域、數(shù)據(jù)中心或區(qū)域中斷期間也能保持運行。

例如，使用 YugabyteDB，您只需部署一個多節(jié)點分布式 Postgres 集群，讓節(jié)點處理容錯和高可用性。節(jié)點直接通信。如果一個節(jié)點發(fā)生故障，其他節(jié)點將檢測到中斷。由于其余節(jié)點具有冗余、一致的數(shù)據(jù)副本，因此它們可以立即開始處理先前發(fā)送到故障節(jié)點的應用程序請求。YugabyteDB 提供 RPO = 0(無數(shù)據(jù)丟失)和 3-15 秒范圍內(nèi)的 RTO(取決于數(shù)據(jù)庫和 TCP/IP 配置默認值)。

通過這種方式，您可以構(gòu)建永遠不會失敗的新一代人工智能應用程序和自主代理，即使在區(qū)域級事故和其他災難性事件中也是如此。

總結(jié)

得益于 pgvector 等擴展，PostgreSQL 已超越了傳統(tǒng)的關(guān)系數(shù)據(jù)庫用例，現(xiàn)在已成為生成式 AI 應用程序的有力競爭者。然而，使用嵌入可能會帶來一些挑戰(zhàn)，包括大量內(nèi)存和存儲消耗、計算密集型相似性搜索、數(shù)據(jù)隱私問題以及對高可用性的需求。

分布式 PostgreSQL 部署提供可擴展性、負載平衡和地理分區(qū)，確保數(shù)據(jù)駐留合規(guī)性和不間斷運行。通過利用這些分布式系統(tǒng)，您可以構(gòu)建可擴展且永不失敗的可擴展 Gene AI 應用程序。