Prisma Postgres 常見問題

關於 Prisma Postgres 的工作方式、查詢計費方式以及它如何與 Prisma ORM 整合的常見問題。

通用

我可以在沒有 Prisma ORM 的情況下使用 Prisma Postgres 嗎？

是的，您可以透過直接連線，將 Prisma Postgres 與任何資料庫庫或工具結合使用。

如何從 GitHub 登入切換到電子郵件和密碼登入？

如果您之前使用 GitHub 註冊，並希望切換到電子郵件和密碼登入，請遵循以下步驟

1. 驗證您的 GitHub 電子郵件地址
   • 檢查與您的 GitHub 帳戶關聯的主要電子郵件地址（例如，從您的 GitHub 個人資料或通知設定中檢視）。
2. 建立新的電子郵件/密碼帳戶
   • 前往電子郵件/密碼註冊頁面。
   • 使用與您的 GitHub 帳戶繫結的相同電子郵件地址來建立新帳戶。
   • 我們的系統將自動把您的新電子郵件/密碼帳戶連線到您現有資料。
3. 測試您的登入
   • 退出登入，然後嘗試使用您剛建立的電子郵件和密碼登入。

注意

如果您遇到任何問題，請聯絡我們的支援團隊以協助關聯您的帳戶。

VS Code 無法識別 $extends 方法

如果您將 Prisma Client Accelerate 擴充套件新增到當前在 VS Code 中開啟的現有專案中，編輯器可能無法立即識別 $extends 方法。

這可能是 TypeScript 伺服器尚未識別重新生成的 Prisma Client 的問題。要解決此問題，您需要重新啟動 TypeScript。

1. 在 VS Code 中，開啟命令面板。您可以按 F1 或選擇檢視 > 命令面板來執行此操作。
2. 輸入 typescript 並選擇並執行TypeScript: Restart TS server命令。

VS Code 現在應該能夠識別 $extends 方法了。

定價

Prisma Postgres 根據消耗的運算元和儲存空間計費。訪問定價頁面瞭解詳情，並閱讀我們解釋基於操作計費的部落格文章，以詳細瞭解操作是什麼以及此定價模型如何運作。

什麼是操作？

每次您與資料庫互動時都會計算一個操作。無論是讀取、寫入、簡單還是複雜，都只計為一個操作。

一個操作可以是

• 一個 Prisma ORM 查詢（使用 Prisma ORM 時）
• 一個 SQL 查詢（使用直接 TCP 連線時）

查詢執行時間會影響 Prisma Postgres 中的定價嗎？

不，Prisma Postgres 的成本僅基於運算元，而不是執行這些操作所需的計算量。

無論查詢執行時間是 10 毫秒還是 10 秒，其定價影響都保持不變。

使用 Prisma ORM 和直接 TCP 連線的定價有何不同？

基於操作的定價基本原則對於 Prisma ORM 和直接 TCP 連線保持不變。然而，根據您使用 Prisma ORM 還是直接 SQL 與資料庫互動，一個操作的定義有所不同

• 使用 Prisma ORM 時：透過 Prisma Client 傳送的查詢（例如 prisma.user.findMany()）
• 使用其他工具時：透過直接連線傳送的 SQL 查詢（例如 SELECT * from "User"）

請注意，單個 Prisma ORM 查詢可能會轉換為多個 SQL 查詢，這可能使得使用 Prisma ORM 比直接 SQL 更經濟。

讀寫查詢的成本相同嗎？

是的，讀寫查詢都同樣被計算為操作，並以相同的方式計費。

SELECT 1 查詢是否算作可計費操作？

是的，像 SELECT 1 這樣的查詢算作一個操作，並將相應地計費（即使查詢中沒有實際訪問任何資料）。

我如何估算 Prisma ORM 中的運算元？

您可以透過將 Prometheus 等應用程式效能監控工具與 Prisma ORM 的metrics 預覽功能整合，來估算 Prisma ORM 中的操作使用量。啟用 metrics 預覽功能後，檢視 prisma_client_queries_total 指標以獲取運算元。

Prisma Postgres 使用 prisma_client_queries_total 計數器，該計數器跟蹤傳送到資料庫的每個客戶端操作以計算您的費用。有關配置 Prometheus 和監控應用程式的詳細分步教程，請參閱我們的完整指南。

我可以使用哪些策略來最佳化每個操作的成本？

Prisma Postgres 按操作計費。您在單個操作中執行的操作越多，費用就越低。以下是一些減少運算元的技巧

• 使用 createMany、updateMany 或 deleteMany 批次寫入，而不是迴圈進行單行呼叫。

  // One operation, three users
  await prisma.user.createMany({
    data: [
      { name: 'Alice' },
      { name: 'Bob'   },
      { name: 'Carol' },
    ],
  })

• 使用connectOrCreate或set等巢狀關係輔助函式，以在單個操作中建立或連結相關記錄。

  // Post and (if needed) its author, all in one request
  await prisma.post.create({
    data: {
      title: 'Hello World',
      author: {
        connectOrCreate: {
          where:  { email: 'alice@example.com' },
          create: { name: 'Alice', email: 'alice@example.com' },
        },
      },
    },
  })

• 當各個查詢之間不相互依賴時，優先使用常規（陣列）事務而非互動式事務。

  // Interactive transaction: counted as 2 operations
  await prisma.$transaction(async (tx) => {
    await tx.user.create({ data: { name: 'Alice' } })
    await tx.post.create({ data: { title: 'Hello', authorId: 1 } })
  })
  
  // Array transaction: counted as 1 operation
  await prisma.$transaction([
    prisma.user.create({ data: { name: 'Alice' } }),
    prisma.post.create({ data: { title: 'Hello', authorId: 1 } }),
  ])

如果後續查詢需要早期查詢的結果（例如，您需要剛建立的使用者 ID），請堅持使用互動式事務以確保正確性。否則，批次處理和陣列事務可讓您將多個查詢合併為一個計費操作，從而降低您的操作計數和成本。

是否有示例工作負載來估算我的預期費用？

我們將演示三個示例工作負載，並估算小型、中型和大型工作負載的費用。每個示例都結合了實際的月活躍使用者數 (MAU)、每個使用者的典型每日活動量以及大致的儲存佔用空間。

我們將使用以下公式估算月度賬單

total_ops            = MAUs x actions_per_user_per_day x 30      
billable_ops         = total_ops - 100_000
ops_cost             = (billable_ops ÷ 1_000_000) x plan_rate

billable_storage_GB  = storage_used_GB - free_storage_for_plan
storage_cost         = billable_storage_GB x storage_rate_for_plan

total_monthly_cost   = ops_cost + storage_cost + base_plan_fee

注意

您可以使用自己的月活躍使用者數、活動級別和已用儲存空間，利用上述公式估算任意套餐的成本。

我們將把每個工作負載與一個套餐及其相應的定價詳情關聯起來，例如，小型工作負載對應Starter plan（入門套餐），中型工作負載對應Pro plan（專業套餐），大型工作負載對應Business Annual plan（商業年度套餐）。然後我們將對示例工作負載應用這些公式，以生成月度賬單的粗略估算。例如

定價詳情

以下是每個定價套餐的詳細資訊

• Starter plan（入門套餐） - 每百萬操作 $18
  • 基本套餐費 - 每月 $0
  • 儲存 - 1 GB 免費，之後每額外 1 GB $2
• Pro plan（專業套餐） - 每百萬操作 $8
  • 基本套餐費 - 每月 $49.00
  • 儲存 - 5 GB 免費，之後每額外 1 GB $1.5
• Business Annual plan（商業年度套餐） - 在每月 50-100M 使用範圍內每百萬操作 $4
  • 基本套餐費 - 每月 $129.00
  • 儲存 - 10 GB 免費，之後每額外 1 GB $1

您還可以在定價頁面上了解每個套餐的更多定價詳情。

Starter plan（入門套餐）上的小型工作負載示例:

一個擁有約 500 月活躍使用者 (MAU) 的愛好或早期階段副專案。每個使用者每天執行約 10 次操作，整個資料庫使用約 0.5 GB 儲存空間。基於這些假設，您將使用以下公式計算月度賬單

• total_ops（總運算元） = 500 x 10 x 30 = 150000
• billable_ops（可計費運算元） = 50000
• ops_cost（操作成本） = (50000 ÷ 1000000) x $18 = $0.90
• storage_cost（儲存成本） = $0 (0.5 GB 低於 1 GB 免費額度)
• base_plan_fee（基本套餐費） = $0

total_monthly_cost（月總成本） = 每月 $0.90

Pro plan（專業套餐）上的中型工作負載示例:

一個不斷增長的 SaaS 產品，服務約 5000 月活躍使用者 (MAU)。高階使用者平均每天執行約 40 次操作，應用程式儲存約 6 GB 資料。基於這些假設，您將使用以下公式計算月度賬單

• total_ops（總運算元） = 5000 x 40 x 30 = 6000000
• billable_ops（可計費運算元） = 5900000
• ops_cost（操作成本） = (5900000 ÷ 1000000) = 5.9 x $8 = $47.20
• storage_cost（儲存成本） = (6 GB - 5 GB) x $1.50 = $1.50
• base_plan_fee（基本套餐費） = $49.00

total_monthly_cost（月總成本） = $47.20 + $1.50 + $49.00 = 每月 $97.70

Business Annual plan（商業年度套餐）上的大型工作負載示例:

一個生產級的面向消費者應用程式，處理約 50000 月活躍使用者 (MAU)。每個使用者每天約 60 次操作的重度使用產生大量流量，資料集達到約 40 GB。基於這些假設，您將使用以下公式計算月度賬單

• total_ops（總運算元） = 50000 x 60 x 30 = 90000000
• billable_ops（可計費運算元） = 89900000
• ops_cost（操作成本） = (89900000 ÷ 1000000) = 89.9 x $4 = $359.6
• storage_cost（儲存成本） = (40 GB - 10 GB) x $1 = $30.00
• base_plan_fee（基本套餐費） = $129.00

total_monthly_cost（月總成本） = $359.6 + $30.00 + $129.00 = 每月 $518.60

快取操作的計費方式相同嗎？

每個請求，無論是命中資料庫還是從快取中提供，都算作一個操作。Prisma Postgres 採用統一的操作單價，且不收取出口流量費用，因此快取響應不會產生額外或減少的費用。這種統一費率使計費模型可預測，並避免了按請求計費的複雜性。

快取

Prisma Postgres 包含內建連線池和全域性快取。這些功能透過最佳化查詢的路由和快取方式來提高效能。

Prisma Postgres 的快取層如何知道從哪個區域獲取快取？

在底層，Prisma Postgres 的快取層使用 Cloudflare，它透過 Anycast 進行網路定址和路由。傳入請求將被路由到其網路中最近的、有能力高效處理請求的資料中心或“節點”。要了解更多關於其工作原理的資訊，我們建議查閱 Anycast。

如何使 Prisma Postgres 的快取失效？

如果您使用的是付費套餐，可以透過 $accelerate.invalidate API 按需使快取失效，或者您可以在專案級別上，每天最多使整個快取失效五次。此限制是根據您的套餐設定的。您可以透過 Accelerate 配置頁面管理此功能。

Prisma Postgres 快取層的一致性模型是什麼？

Prisma Postgres 中的快取層沒有一致性模型。它不是一個需要節點達成共識的分散式系統（因為資料只儲存在離使用者最近的快取節點中）。然而，Prisma Postgres 快取節點中快取的資料不會傳播到其他節點，因此快取層在設計上不需要一致性模型。

Prisma Postgres 實現了穿透式快取策略，特別適合讀取密集型工作負載。

快取提供的資料的新鮮度取決於查詢中定義的快取策略。有關為查詢選擇正確快取策略的更多資訊，請參閱此部分。

Prisma Postgres 的快取層與其他快取工具（如 Redis）有何不同？

Prisma Postgres 的快取層

• 是一種專用快取，允許您透過快取策略在查詢級別最佳化程式碼中的資料訪問。另一方面，Redis 和 Memcached 等工具是通用快取，旨在具有適應性和靈活性。
• 是一項託管服務，可減少構建和維護快取服務所需的時間、風險和工程工作。
• 預設情況下是全球分散式，可減少查詢延遲。其他快取工具需要額外的配置才能在全球範圍內可用。

我何時不應使用 Prisma Postgres 的快取功能？

Prisma Postgres 的快取層是一個全域性資料快取和連線池，允許您在查詢級別最佳化程式碼中的資料訪問。雖然使用 Prisma Postgres 快取可以極大地提升應用程式的效能，但它可能並非總是您用例的最佳選擇。

如果出現以下情況，此全域性快取功能可能不適合您的應用程式

• 您的應用程式僅在特定區域內使用，並且您的應用程式伺服器和資料庫都位於同一網路中的同一區域。例如，如果您的應用程式伺服器和資料庫位於同一區域和網路，資料庫查詢可能會快得多。然而，如果您的應用程式伺服器與資料庫位於不同的區域或網路，快取節點將加快您的查詢速度，因為資料將快取到離您應用程式最近的資料中心。

• 您的應用程式資料始終需要是最新的，這使得難以建立合理的快取策略。

配置 cacheStrategy 時，ttl 引數的最大允許值是多少？

存活時間（ttl）引數可以設定為最長一年。但是，需要注意的是，如果快取中的專案不經常被訪問，它們可能會被逐出。

根據我們的實驗，我們觀察到快取項大約可以保留 18 小時。雖然如果快取項被頻繁訪問，它們可能會在快取中保留更長時間，但這不能保證。

:::[注意]

即使是頻繁訪問的項也可能偶爾從快取中被逐出。無論其活動級別如何，一個項不太可能存活一個月或更長時間。

:::

為什麼有時我會看到意想不到的快取行為？

當觀察到專案負載較高時，Prisma Postgres 的快取層效能最佳。許多快取操作，例如將資料提交到快取和重新整理陳舊資料，都是非同步發生的。在對快取層進行基準測試時，我們建議使用迴圈或負載測試方法。這將更好地模擬高負載場景，並減少低頻率操作帶來的異常值。

Prisma 操作透過 HTTP 傳送到 Prisma Postgres。因此，對 Prisma Postgres 的首次請求必須建立 HTTP 握手，這可能會導致額外的延遲。我們正在探索未來減少這種初始請求延遲的方法。

Prisma Postgres 的快取節點在哪些地區可用？

Prisma Postgres 的快取層執行在 Cloudflare 的網路上，快取命中由 Cloudflare 的 300 多個地點提供服務。您可以在此處找到 Prisma Postgres 快取節點的可用區域：https://www.cloudflare.com/network/。

使快取查詢結果失效需要多長時間？

由於快取需要在全球範圍內清除，因此很難提供具體的時間範圍。然而，快取資料最終會保持一致，並且通常會在幾秒鐘內傳播到所有 PoP。在極少數情況下，可能需要更長時間。

這是一個演示應用程式，用於測試使快取查詢結果失效所需的時間。

失效和重新驗證之間有什麼區別？

失效 (Invalidate)：快取條目被刪除，下次請求時將獲取新資料，導致快取未命中。這會移除陳舊資料，但在快取重新填充之前可能會導致響應變慢。

重新驗證 (Revalidate)：快取條目被主動更新，確保下一次請求使用快取中的最新資料。這使快取保持有效，並透過避免快取未命中保持更快的響應時間。

什麼是按需快取失效？

按需快取失效允許應用程式在特定快取資料發生變化時立即更新，而無需等待常規快取重新整理週期。這可確保為使用者提供準確和最新的資訊。

我何時應該使用快取失效 API？

當資料一致性無法等待快取的標準過期或重新驗證時，快取失效 API 至關重要。主要用例包括

• 內容更新：當發生需要立即可見的關鍵更改時，例如已釋出文章的編輯、產品更新或個人資料修改。
• 庫存管理：在即時應用程式（如庫存或預訂系統）中，庫存水平、可用性或預訂狀態必須反映最新資訊。
• 高優先順序資料：對於時間敏感的資料，如突發新聞或緊急通知，使用者立即看到最新資訊至關重要。

在這些場景中使用按需快取失效有助於僅重新整理必要的資料，在保持系統性能的同時，確保為使用者提供準確、最新的資訊。

連線池

我可以增加我的 Prisma Postgres 例項的查詢持續時間和響應大小限制嗎？

是的，您可以根據您的訂閱套餐提高 Prisma Postgres 的限制。以下是可配置的限制

限制	Starter	Pro Plan	Business Plan
查詢超時	最長 10 秒	最長 20 秒	最長 60 秒
互動式事務超時	最長 15 秒	最長 30 秒	最長 90 秒
響應大小	最長 5 MB	最長 10 MB	最長 20 MB

請檢視定價頁面，瞭解可用套餐及其相應限制的更多詳情。

警告

雖然您可以根據您的訂閱套餐提高這些限制，但仍然建議您最佳化資料庫操作。在我們的故障排除指南中瞭解更多資訊。

查詢最佳化

Prisma Postgres 允許透過 Prisma Optimize 進行查詢最佳化，並提供效能建議以幫助您在開發過程中改進資料庫查詢。您可以將其與 Prisma Postgres 一起啟用，或者也將其與您自己的資料庫一起使用，但設定和整合步驟有所不同。

你能自動實現最佳化嗎？

Prisma Postgres 的查詢最佳化功能提供有關如何改進資料庫查詢的見解和建議。它不會更改任何現有查詢或您的 Prisma 架構。

錄製會話保留多長時間？

儲存保留期沒有限制。查詢效能錄製會話將一直儲存，直到您明確刪除它。

推薦限額每月重置嗎？

是的，推薦使用量在每個日曆月月初重置。例如，如果您在月底前使用了 5 次推薦，那麼下個月初您的使用量將重置為 0。

如果我超出入門套餐的推薦限額，會被收費嗎？

是的，如果您使用的是入門套餐，在一個計費週期內超出 5 次推薦將導致在該週期結束時產生 $5 的費用。有關更多資訊，請訪問我們的定價頁面。

Prisma AI 推薦的檢視如何跟蹤計費？是根據生成的推薦還是檢視的推薦來計數？

它們是根據檢視過的推薦來計數的。一旦您從推薦列表中點選一個推薦並檢視其詳情頁面，它就被視為已檢視。

我可以在生產環境中啟用 Prisma Postgres 的查詢最佳化嗎？

不，Prisma Postgres 的查詢最佳化不應在生產環境中使用。它專為本地開發而設計，在該階段提供有價值的見解和最佳化。雖然在技術上可以在生產環境中執行它，但這樣做可能會導致效能問題或意外行為，因為它不是為了處理生產工作負載的複雜性和規模而構建的。為了獲得最佳體驗，我們建議您僅在開發環境中測試查詢最佳化。

您可以在客戶端擴充套件中使用 enable 屬性，以使其僅在開發環境中執行。預設情況下，enable 屬性設定為 true。

script.ts

import { PrismaClient } from '@prisma/client'
import { withOptimize } from "@prisma/extension-optimize"

const prisma = new PrismaClient().$extends(
  withOptimize({
    apiKey: process.env.OPTIMIZE_API_KEY,
    enable: process.env.ENVIRONMENT === 'development',
  })
);

為什麼我看到“[optimize] HTTP 409 Conflict: There is no active recording to write queries to”警告？

當 Prisma Optimize 接收到查詢但沒有活動的錄製會話時，可能會出現此警告。通常，這可能是因為 Prisma Optimize 在您的生產環境中意外啟用。Prisma Optimize 專門為本地開發環境設計，不應在生產環境中啟用。為避免此警告，請確保 Prisma Optimize 配置為僅在開發期間執行。

如果您在開發環境中看到此警告，請確保您已在 Prisma Optimize 控制面板中啟動了錄製會話。