跳到主要內容

在 Prisma Postgres 中快取查詢

Prisma Postgres 支援內建查詢快取，以減少資料庫負載並提高查詢效能。您可以使用所有讀取查詢中可用的 cacheStrategy 選項來配置快取行為。

此功能由透過 Prisma Accelerate 啟用的內部快取層提供支援，但除非您使用自己的資料庫，否則無需直接與 Accelerate 互動。

快取策略​

對於 Prisma Client 中的所有讀取查詢，您可以定義 cacheStrategy 引數來配置快取行為。快取策略允許您定義快取的兩個主要特性：

  • 存活時間 (TTL)： 快取響應被視為“新鮮”的持續時間（以秒為單位）。
  • 失效時重新驗證 (SWR)： 在後臺重新整理快取時，失效的快取響應被視為可接受的持續時間。

存活時間 (TTL)​

存活時間 (TTL) 決定快取資料被視為新鮮的時長。透過以秒為單位指定 ttl，您可以控制快取中資料保持有效的持續時間。當執行讀取查詢時，如果快取響應在 ttl 限制內，Prisma Client 會從快取中檢索資料，而無需查詢資料庫。如果快取資料不可用或已過期，Prisma Client 會查詢資料庫並將結果儲存在快取中以供將來請求使用。

在 cacheStrategy 中使用 ttl 並以秒為單位指定查詢的 TTL

await prisma.user.findMany({
  cacheStrategy: {
    ttl: 60,
  },
});

在指定 60 秒的 TTL 後，在整個 TTL 持續時間內，大多數請求都會導致快取命中

TTL

TTL 對於減少不需要頻繁更新的資料的資料庫負載和延遲非常有用。

使 TTL 失效並保持快取查詢結果最新​

如果您的應用程式需要即時或近即時資料，快取失效可確保使用者看到最新資料，即使使用較大的 ttl（存活時間）也是如此。透過使快取失效，您可以繞過較長的快取週期，在需要時顯示即時資料。

例如，如果儀表板顯示客戶資訊，並且客戶的聯絡方式發生變化，TTL（存活時間）設定可確保快取在設定的持續時間後自動過期。這允許系統在下次訪問時僅重新整理更新的資料，確保支援人員始終看到最新資訊，而無需手動重新整理快取。

然而，在 TTL 過期之前需要立即更新的情況下，快取失效允許系統主動從快取中清除特定資料。這會強制立即重新整理更新的資訊，因此支援人員始終擁有最新的詳細資訊，而無需等待 TTL 觸發。

要使快取查詢結果失效，您可以新增標籤，然後使用 $accelerate.invalidate API。

注意

按需快取失效功能僅適用於我們的付費方案。有關更多詳情，請參閱我們的定價。

要使以下查詢失效，您需要在 $accelerate.invalidate API 中提供快取標籤

await prisma.user.findMany({
    cacheStrategy: {
      ttl: 60,
      tags: ["findMany_users"],
    },
});

// This is how you would invalidate the cached query above.
await prisma.$accelerate.invalidate({
    tags: ["findMany_users"],
});

失效時重新驗證 (SWR)​

失效時重新驗證 (SWR) 允許您控制 Prisma Postgres 在後臺獲取新鮮資料時可以提供陳舊快取資料的時間。當執行讀取查詢時，Prisma Postgres 會根據 swr 持續時間檢查快取響應的年齡。如果快取資料在 swr 限制內，Prisma Postgres 會提供陳舊資料，同時透過從資料庫獲取最新資料來重新整理快取。

在 cacheStrategy 中使用 swr 並以秒為單位指定查詢的 SWR

await prisma.user.findMany({
  cacheStrategy: {
    swr: 60,
  },
});

當指定 60 秒的 SWR 時，快取在每次請求後在後臺自行重新整理之前提供陳舊資料。

SWR

使 SWR 失效並保持快取查詢結果最新​

如果您的應用程式需要即時或近即時資料，快取失效可確保使用者看到最新資料，即使使用較大的 swr（失效時重新驗證）也是如此。透過使快取失效，您可以繞過較長的快取週期，在需要時顯示即時資料。

例如，考慮一個顯示倉庫產品庫存水平的儀表板。透過 SWR（失效時重新驗證）設定，儀表板可以立即顯示上次已知的庫存資料，即使它略有過期，同時在後臺獲取新資料。這確保了員工可以繼續使用最新資訊而無需等待，並且庫存水平會在重新驗證完成後立即更新。

然而，在需要立即更新庫存資料的情況下——例如，如果產品庫存不足且需要即時精確的計數——快取失效允許系統主動從快取中清除特定資料。這會強制立即重新整理最新的庫存資料，因此員工始終擁有最新的資訊，而無需等待 SWR 完成重新驗證。

要使快取查詢結果失效，您可以新增標籤，然後使用 $accelerate.invalidate API。

注意

按需快取失效功能僅適用於我們的付費方案。有關更多詳情，請參閱我們的定價。

要使以下查詢失效，您需要在 $accelerate.invalidate API 中提供快取標籤

await prisma.user.findMany({
    cacheStrategy: {
      swr: 60,
      tags: ["findMany_users"],
    },
});

// This is how you would invalidate the cached query above.
await prisma.$accelerate.invalidate({
    tags: ["findMany_users"],
});

選擇快取策略​

快取有助於您改善查詢響應時間並減少資料庫負載。然而，這也意味著您可能會向客戶端提供陳舊資料。是否可以接受陳舊資料以及接受到何種程度取決於您的用例。ttl 和 swr 是您可以用來調整快取行為的引數。

使用 TTL 的快取策略​

當陳舊快取資料可接受時，使用 TTL 來減少資料庫負載。

用例：電子商務應用程式中的產品目錄​

考慮一個產品目錄不經常變化的電子商務應用程式。透過設定一個例如 1 小時的 ttl，Prisma Client 可以在該小時內為後續使用者請求提供快取的產品資料，而無需訪問資料庫。這顯著減少了資料庫負載並提高了產品列表頁面的響應時間。

何時使失效： 如果目錄有關鍵更新，例如主要價格變動或產品可用性調整，應立即使快取失效，以防止客戶看到過時資訊。

使用 SWR 的快取策略​

使用 SWR 快速響應請求，同時最小化陳舊資料。雖然它不能減少資料庫負載，但可以顯著提高響應時間。

用例：社交媒體平臺中的使用者資料​

想象一個使用者資料被頻繁訪問的社交媒體平臺。透過利用 swr 持續時間為例如 5 分鐘，Prisma Postgres 可以快速提供快取的使用者資料資訊，減少資料頁面的延遲。同時，在後臺，它會在每次請求後重新整理快取，確保對資料進行的任何更新最終會反映在後續請求中。

何時使失效： 如果使用者對其資料進行了重大更新，例如更改其資料圖片或簡介，應立即使快取失效，以確保關注者無需等待 SWR 重新整理即可看到最新更新。

使用 TTL + SWR 的快取策略​

為了獲得非常快的響應時間並減少資料庫負載，請同時使用 TTL 和 SWR。您可以使用此策略來微調應用程式對陳舊資料的容忍度。

在 cacheStrategy 中使用 ttl 和 swr 並以秒為單位指定查詢的 TTL 和 SWR

await prisma.user.findMany({
  cacheStrategy: {
    ttl: 30,
    swr: 60,
  },
});

當指定 30 秒的 TTL 和 60 秒的 SWR 時，快取在最初 30 秒內提供新鮮資料。隨後，它會提供陳舊資料，直到快取在每次請求後在後臺自行重新整理。

ttl_and_swr.png

用例：新聞文章​

考慮一個新聞應用程式，其中文章被頻繁訪問但不需要即時更新。透過設定 2 小時的 ttl 和 5 分鐘的 swr 持續時間，Prisma Client 可以快速提供快取的文章，減少讀者的延遲。只要文章在 ttl 範圍內，使用者就能獲得快速響應。ttl 過期後，Prisma Client 會繼續提供陳舊文章，最長可再提供 5 分鐘，同時針對新查詢從資料庫中重新驗證快取以獲取最新新聞。這有助於在效能和新鮮度之間保持平衡。

何時使失效： 如果釋出了關鍵更新或突發新聞文章，應立即使快取失效，以確保讀者及時看到最新資訊。這種方法對於某些新聞專案可能需要覆蓋正常快取週期以確保及時性的應用程式特別有用。

按需快取失效​

如果您的應用程式需要即時或近即時資料，快取失效可確保使用者看到最新資料，即使使用較大的 ttl（存活時間）或 swr（失效時重新驗證）快取策略也是如此。透過使快取失效，您可以繞過較長的快取週期，在需要時顯示即時資料。

您可以使用 $accelerate.invalidate API 使快取失效

注意

要以程式設計方式使快取查詢失效，需要付費方案。有關更多詳情，請參閱我們的定價。

await prisma.user.findMany({
  where: {
    email: {
      contains: "alice@prisma.io",
    },
  },
  cacheStrategy: {
    swr: 60,
    ttl: 60,
    tags: ["emails_with_alice"],
  },
});

您需要在 $accelerate.invalidate API 中提供快取標籤

try {
  await prisma.$accelerate.invalidate({
    tags: ["emails_with_alice"],
  });
} catch (e) {
  if (e instanceof Prisma.PrismaClientKnownRequestError) {
    // The .code property can be accessed in a type-safe manner
    if (e.code === "P6003") {
      console.log(
        "The cache invalidation rate limit has been reached. Please try again later."
      );
    }
  }
  throw e;
}

探索演示應用，瞭解 Prisma Postgres 中的快取查詢結果如何按需失效，並清晰地顯示在時間軸上。

預設快取策略​

Prisma Postgres 預設情況下不使用快取，以避免意外問題。雖然快取可以提高效能，但不正確的使用可能導致錯誤。

例如，如果在關鍵路徑上執行查詢而未指定快取策略，結果可能不正確，並且沒有明確的解釋。此問題通常發生在無意中啟用了隱式快取時。

為了避免此類問題，您必須明確選擇啟用快取。這確保您知道快取預設情況下未啟用，從而防止潛在的錯誤。

注意

當未指定快取策略或發生快取未命中時，快取層會將所有查詢透過靠近資料庫區域的連線池例項路由到資料庫。

© . This site is unofficial and not affiliated with Prisma Data, Inc.