Cloudflare、Unikernels 與裸金屬：Prisma Postgres 查詢的生命週期

回顧：什麼是 Prisma Postgres？

如果您還沒聽說：Prisma Postgres 是第一個基於 unikernel 構建的資料庫。如果您錯過了，這裡有一個100秒的快速摘要

基於下一代基礎設施構建

Prisma Postgres 不僅僅是另一個 AWS 封裝！其架構從基本原理出發精心設計，並構建在 unikernel、Unikraft Cloud 和 Cloudflare Workers 等下一代基礎設施之上。

這些技術的結合提供了獨特的優勢和強大的功能集。

無冷啟動、全域性快取、連線池及更多

開發人員將 Prisma Postgres 用作無伺服器資料庫時可獲得以下優勢：

• 零冷啟動：即時訪問資料庫，無延遲。
• 慷慨的免費套餐：每月10萬次操作，1GiB儲存空間和10個數據庫。
• 全域性快取層：查詢響應可輕鬆在邊緣快取。
• 內建連線池：擴充套件您的應用，無需擔心 TCP 連線。
• 效能提示：AI 驅動的建議，助您加快查詢速度。
• 簡單的按用量付費定價：基於操作和儲存的成本可預測。

嘗試 Prisma Postgres

Prisma Postgres 查詢的生命週期

在簡短回顧之後，讓我們深入瞭解 Prisma Postgres 用於實現這些優勢的技術棧。劇透：這是 Prisma Postgres 查詢生命週期中涉及的所有元件的完整概述

在接下來的部分中，我們將仔細研究每個階段，並解釋幕後發生的事情。

階段1：一切始於 Prisma ORM

Prisma ORM 是 Prisma Postgres 查詢自然開始的地方。

在應用伺服器上使用 Prisma Postgres 無需查詢引擎

如果您過去使用過 Prisma ORM，您可能知道它使用一個用 Rust 實現的查詢引擎（Query Engine），它作為二進位制檔案在您的應用伺服器上執行。

請注意，雖然我們在此語境中仍在談論用 Rust 編寫的查詢引擎，但它目前正在用 TypeScript 進行重寫。點選此處瞭解更多 here。

查詢引擎的核心職責是：

• 根據高階 ORM 查詢（用 JS/TS 編寫）生成高效的 SQL 查詢
• 管理資料庫連線池

然而，使用 Prisma ORM 搭配 Prisma Postgres 的妙處在於，您無需在應用伺服器上執行查詢引擎。相反，您將使用一個不帶查詢引擎的超輕量級 Prisma ORM 版本。生成 SQL 查詢和管理 TCP 連線的繁重工作被進一步下推到 Prisma Postgres 之上的連線池中。

將連線池託管在 Prisma Postgres 基礎設施上的這種方法具有主要優勢：將應用開發人員從管理連線池的任務中解放出來，讓他們能夠專注於自己的資料需求和查詢。這在無伺服器和邊緣函式等短生命週期環境中也特別有用，因為在這些環境中反覆重新建立連線池會導致主要的效能開銷。

使用快取策略定義 Prisma ORM 查詢

出於本文的目的，我們使用以下 Prisma ORM 查詢

此查詢從資料庫中獲取所有已釋出的文章，並額外指定了兩個與 Prisma Postgres 快取相關的引數

• 存活時間 (ttl)：決定快取資料被認為是新鮮的時長。當您設定 TTL 值時，Prisma Postgres 將在此持續時間內提供快取資料，而無需查詢資料庫。
• 過期再驗證 (swr)：允許 Prisma Postgres 在後臺獲取新資料時提供陳舊的快取資料。當您設定 SWR 值時，Prisma Postgres 將在該持續時間內繼續提供快取資料，即使已超出 TTL，同時從資料庫更新快取中的新資料。

在此示例中，資料將被視為新鮮 30 秒 (TTL)。之後，在接下來的 60 秒 (SWR) 內，Prisma Postgres 的快取將提供陳舊資料，同時在後臺獲取新鮮資料。

Prisma Postgres 從靠近您應用的邊緣位置提供快取資料。如果您將應用部署到多個位置，這個全域性快取可以顯著提高您應用的效能！

透過 HTTP 執行查詢

那麼，當上述查詢在應用中執行時，接下來會發生什麼？由於查詢引擎已被下推到技術棧的更深層，在此階段發生的一切都只是一個 HTTP 請求，傳送到 Prisma Postgres 基礎設施的第一個認證和路由層。此 HTTP 請求承載著查詢的輕量級 JSON 表示。它看起來像這樣

請注意，selection 引數指定了應從資料庫中獲取的欄位。由於我們未在查詢中使用 select 或 include 選項，因此其值簡單地為 "$scalars": true，這意味著目標模型的所有標量欄位都將從資料庫返回。

請求的下一步將由 Prisma Postgres 的認證和快取層進行評估。

階段2：認證請求

在命中快取以檢查查詢結果是否可以從那裡提供之前，查詢需要進行認證。Prisma Postgres URL 始終包含一個編碼使用者憑據的 apiKey 引數

認證層使用 Cloudflare Workers 實現，因此與查詢的來源物理距離很近。它使用 apiKey 值來識別使用者、驗證訪問許可權並將請求路由到下一階段。

階段3：快取與否

認證後，HTTP 請求將到達 Prisma Postgres 基礎設施的下一層，該層也透過 Cloudflare Workers 實現

此路由層的主要目的是確定是否需要啟用 Prisma Postgres 快取

• 如果查詢設定了 swr 和/或 ttl 選項，查詢將進入 Prisma Postgres 快取路徑。
• 如果查詢沒有這些快取選項中的任何一個，它將直接進入下一階段。

那麼，讓我們來探究透過 Prisma Postgres 快取層的路徑。

Prisma Postgres 快取基於 Cloudflare Workers 構建，充分利用了官方的 Cloudflare Cache API。

作為快取鍵，它使用基於整個 Prisma ORM 查詢（包括查詢引數的值，例如上述情況中的 published: true）計算出的雜湊值。這種方法傾向於快取未命中，並且僅在100%確定該精確查詢已傳送到資料庫並且其結果之前已被快取時，才從快取返回資料。

您可以在 Prisma Postgres 控制檯中檢視快取行為的統計資料

現在我們假設我們之前的查詢繼續向下傳輸到 Prisma Postgres 技術棧，並且未由快取提供服務。接下來會發生什麼？

階段4：命中連線池

如果查詢結果尚未被快取，之前的 HTTP 請求將轉發到下一站：Prisma Postgres 的連線池（它部署在與資料庫例項物理距離很近的虛擬機器上）。

在我們最近的文章中瞭解更多關於連線池的重要性：《透過連線池挽救黑色星期五》

請注意，這實際上是請求可能傳播更長距離的第一次（也是唯一一次），因為它現在離開了 Cloudflare 區域的地理範圍。

這些虛擬機器託管著從應用伺服器中移出的查詢引擎（如階段1所述）。因此，在此階段，Prisma Postgres 的連線池不僅會找到一個空閒連線來實際執行查詢，還會生成將傳送到 Prisma Postgres 的 SQL 語句。這現在透過與資料庫建立的“老式” TCP 連線完成。

階段5：進入 unikernel 資料庫

Prisma Postgres 基於 unikernel （可理解為“超專業作業系統”）執行，它們作為超輕量級微虛擬機器執行在我們自己的裸金屬伺服器上。

檢視《搶先體驗公告》瞭解該架構的詳細資訊、我們與 Unikraft 的合作，以及實現 Prisma Postgres 效能優勢的毫秒級雲棧。

以下是 Unikraft Cloud 的 核心元件的概述，這些元件實現了 Prisma Postgres 例項的閃電般啟動速度

這些元件協同工作方式如下：

• 定製控制器和代理：一個定製的平臺控制器，提供一流的、響應式的、毫秒級語義和可伸縮性。為了加快網路處理速度，Unikraft Cloud 將此控制器與一個定製代理耦合，該代理負責負載均衡並能夠非常快速地響應傳入請求。此代理是 Prisma Postgres 與連線池的 TCP 連線被管理的地方。
• 基於 Firecracker 和 unikernel 的快速虛擬機器監視器 (VMM)：Unikraft Cloud 的 unikernel 使用僅包含 Prisma Postgres 的精簡映象——別無他物。與 Firecracker VMM 的修改版本搭配使用，這些 Prisma Postgres 映象啟動速度極快。
• 快照：Unikraft Cloud 在將 Prisma Postgres 例項縮容到零之前，會對其進行記憶體快照。當它們被喚醒時，它們會從快照恢復，這意味著虛擬機器已經“預熱”並且甚至包含已經活躍的 TCP 連線！

得益於這種高效的技術棧，資料庫例項僅在您實際使用時才會產生費用。這使我們能夠提供慷慨的免費套餐，您可以根據需要啟動任意數量的免費 Prisma Postgres 例項（與其他提供商不同，在其他提供商處，如果您建立多個數據庫例項，通常需要支付固定的月費用）。

回到我們的查詢：在查詢的初始 JSON 表示轉換為高效的 SQL 語句後，查詢最終透過 TCP 到達資料庫層。PostgreSQL 例項使用 Unikraft 的毫秒級雲棧部署在我們自己的裸金屬伺服器上，與連線池距離很近。

這裡的第一站是 Unikraft 代理，它負責維護與連線池的 TCP 連線。

代理現在與 Unikraft 控制器通訊，該控制器負責管理實際的 Prisma Postgres 例項。此時，有兩種可能的狀態：

• 目標 Prisma Postgres 例項已在執行；在這種情況下，代理將直接繼續轉發查詢到它。
• Prisma Postgres 例項當前處於“暫停”狀態；在這種情況下，代理將聯絡 Unikraft 控制器，後者負責識別目標 Prisma Postgres 例項，“喚醒”它並告知代理當前例項狀態。

不要被這裡的“暫停”和“喚醒”術語混淆。得益於超快速的虛擬機器快照（發生在記憶體中）和 unikernel 的輕量級特性，每個例項都可以在幾毫秒內再次喚醒（這就是 Prisma Postgres 例項不受冷啟動影響的秘密）。

Prisma Postgres 架構的下一步是什麼？

儘管我們已經看到當前技術棧及其為開發人員帶來的諸多優勢引起了廣泛的興奮，但我們不會止步於此！

我們認為 Prisma Postgres 未來的迭代中可能進行一些額外的最佳化，最值得注意的是：我們將把連線池移動到執行 Prisma Postgres 例項的同一臺機器上

TCP 連線是整個技術棧中最昂貴的部分，因為每次建立連線都需要進行三次握手。透過將這種 TCP 連線減少為同一臺機器上兩個程序之間發生的本地連線，連線池和資料庫例項之間的物理距離所造成的延遲將變得完全可以忽略不計。

這是 Prisma Postgres 相較於其他基於 AWS（或其他雲提供商）基礎設施的提供商的核心優勢：在使用雲提供商時，無法保證連線池和資料庫例項執行在同一主機上，但始終會存在網路跳躍。

總結

在本文中，我們深入探討了 Prisma Postgres 及其所構建的下一代技術棧。

如果您已經在使用 Prisma ORM，可以嘗試透過 匯入現有資料庫中的資料來體驗 Prisma Postgres。否則，請在您的終端中執行此命令，從頭開始試用 Prisma Postgres