效能基準測試：比較 TypeScript ORM 和資料庫的查詢延遲

目錄

• 太長不看
• 我們的基準測試方法
• 哪個 ORM 最快？
• 提升 Prisma ORM 查詢效能
• 檢視基準測試結果

太長不看

為您的應用程式選擇最佳 ORM 需要考慮多個因素，其中查詢效能是一個重要因素。

為了幫助您決定為 TypeScript 應用程式使用哪個 ORM，我們建立了開源效能基準測試，比較了三個 ORM 庫的查詢效能：Prisma ORM、TypeORM 和 Drizzle ORM（使用它們的查詢 API）。

那麼，哪個 ORM 最快呢？（可能令人不滿意）的答案是：這取決於具體情況！

根據我們收集的資料，無法得出結論說某個 ORM 總是比其他 ORM 表現更好。相反，這取決於具體的查詢、資料集、模式以及查詢執行的基礎設施。

請檢視下面的效能清單，以確保您的 Prisma ORM 查詢達到最佳效能。

我們的基準測試方法

測量和比較查詢效能可能是一項艱鉅的任務，要建立一個公平的比較，需要考慮很多因素。

透過我們的基準測試，我們希望在確保基準測試公平且有意義以幫助人們就下一個專案使用哪個 ORM 做出明智決策，以及保持簡單易懂而不過多地引入間接層或資料處理之間取得平衡。

您可以在此處找到我們用於測量查詢效能的應用程式。

設定

我們為 Prisma ORM、TypeORM 和 Drizzle ORM 建立了 14 個等效查詢。這些查詢是針對一個包含 4 個 Prisma 模型（5 個表，因為有一個隱式多對多關係在底層使用了額外的關係表）的模式傳送的。

每個查詢的延遲透過使用此函式中的performance.now()進行測量

例如，Prisma ORM 的普通findMany查詢可以這樣測量

每個 ORM 每個資料庫都有一個指令碼（例如prisma-postgres.ts），它單獨測量所有 14 個查詢的延遲並將結果儲存在.csv檔案中。

這些指令碼已在 EC2 例項上針對各種提供商託管的 PostgreSQL 資料庫執行

每個指令碼開始時建立資料庫連線，結束時關閉。

資料準備

示例資料使用faker.js進行填充。為了以確定性的方式重新建立相同的示例資料集，我們向faker例項提供了seed值。

資料集的大小在執行基準測試時可配置。它決定了每個表建立的記錄數量。例如，如果建立大小為1000的資料集，則Customer、Product和Address表中將有 1000 條記錄，而Order表中將有 10000 條記錄（Order表因其與Product的多對多關係而乘以10倍，使資料集更真實）。

基準測試執行

要執行基準測試，您可以按如下方式呼叫指令碼

這將對每個表 1000 條記錄的資料集執行預定義查詢 500 次。資料庫 URL 也可以作為環境變數提供。

為了收集資料，我們在生產基礎設施上執行了基準測試，以模擬實際使用場景。指令碼已在具有此規格的 EC2 例項上執行

我們使用的資料庫具有以下規格

釋出基準測試結果

我們已經將執行的基準測試結果釋出在：https://benchmarks.prisma.io。

該表顯示了我們執行的 500 次迭代中查詢延遲的中位數。請注意，我們透過刪除高於第 99 百分位數 (p99) 的值來剔除 500 次迭代中的異常值。

表格的列代表三個 ORM 庫，行顯示了已進行基準測試的查詢。

展開單元格時，您可以檢視有關查詢的一些詳細資訊，例如

• 生成結果的實際程式碼片段及其查詢。
• 一個直方圖，用於視覺化收集資料的分佈。在這些圖表中，左側的條形越高越好，因為它表明更多的迭代具有更低的延遲。

注意事項

基準測試本身就是一個棘手的話題，很難做到完美。當公司釋出效能基準測試時，它們通常會顯示其產品在市場上是最快的，同時又讓其他人難以重現結果，並掩蓋從原始資料收集到結果呈現的路徑。

我們盡力建立了一個公平中立的設定，它易於理解並能產生有意義的結果。即便如此，在檢視基準測試結果時，仍需考慮以下幾點注意事項

• TypeORM 和 Drizzle ORM 的 API 更受限制，一些 Prisma ORM 查詢（如巢狀建立）無法透過其高階抽象表達。在這種情況下，我們不得不回退到使用它們的 SQL 查詢構建器。
• 由於網路延遲，結果在不同迭代之間存在預期差異。為了減少這種影響，我們執行了 500 次基準測試，並在釋出的基準測試結果中顯示了中位數和直方圖。
• 我們進一步確保執行查詢的機器與訪問的資料庫位於同一區域，以將網路延遲降至最低。
• 在我們的基準測試中，我們沒有采取任何措施來減少資料庫級別或作業系統級別快取的影響。
• 所有基準測試迭代都使用相應 ORM / 驅動程式庫的預設連線池大小。
• 雖然我們努力使基準測試設定儘可能真實，但我們不得不在模式和查詢上做出一些權衡。例如，我們沒有向模式新增特殊索引，有時故意使用過於簡單的查詢，以便能夠正確比較每個 ORM 的高階 API。

我們投入了大量精力使您可以輕鬆自行執行基準測試，所以請嘗試一下，如果您想貢獻改進，請隨時聯絡我們！

哪個 ORM 最快？

雖然可能令人不滿意，但答案常常是：這取決於具體情況。效能是一個複雜而細緻的話題，它取決於各種因素，並且眾所周知難以預測。

請參閱下面的效能清單，以確保您的查詢達到最佳速度。

雖然無法對這個問題給出確切的答案，但我們可以嘗試尋找一些模式並進行分析。

不同資料庫提供商之間的低差異

首先，我們發現不同資料庫提供商之間的差異通常可以忽略不計。例如，僅檢視普通的findMany查詢，我們可以從中位數和直方圖分佈中看到，效能的差異很小

大概 RDS 具有優勢，因為基準測試指令碼是在同一安全組內的 EC2 例項上執行的，而 Supabase 和 Neon 資料庫則可透過公共網際網路訪問。

更多資訊，請務必訪問基準測試網站以檢查我們的結果，或使用您選擇的資料庫提供商自行執行基準測試。

大多數查詢效能相似

如果您放大並遠距離觀察結果，您會發現大多數查詢的效能實際上相差無幾，只有幾毫秒的差異。例如，以下是我們從 AWS RDS 收集到的結果

使用者體驗研究表明，低於 100 毫秒的延遲使用者是察覺不到的，並且仍然會讓系統感覺即時響應。因此，在大多數情況下，這些微小差異可能不應該是您為下一個專案選擇 ORM 的主要因素。

當然，資料庫查詢延遲只是您正在構建的應用程式整體效能中的一個因素，因此請務必測量和最佳化其他方面，特別是系統中的所有網路邊界（例如 HTTP 層）。

主要的異常值：巢狀查詢所有

巢狀查詢所有查詢在所有 ORM 和所有資料庫提供商中都特別慢。這是一個簡單的查詢，看起來像這樣

Prisma ORM

Drizzle ORM

TypeORM

以 RDS 為例，這是我們收集的結果中的中位數

此查詢對所有 ORM 來說都比其他查詢慢得多，因為它從兩個不同的表中獲取資料，並且返回的資料量非常可觀。

結論

我們收集的資料無法對每個 ORM 的個體效能得出確切結論。關於查詢效能的殘酷事實是，使用每個 ORM 庫都可以編寫快速查詢，也可以編寫慢速查詢。

最終，應用程式的大部分效能取決於開發人員遵循最佳實踐（請參閱下面的效能清單）、識別慢速查詢並隨著時間推移對其進行最佳化的能力。

提升 Prisma ORM 查詢效能

效能對我們 Prisma 至關重要，我們最近大量關注於改進 Prisma ORM 在這方面的各個方面，例如透過引入使用資料庫級別 JOIN的選項，在v5中實現多項效能改進，將無伺服器冷啟動時間縮短 9 倍，或者在最新5.17.0版本中將$queryRaw的速度提高 2 倍。

Prisma ORM 效能清單

以下是一個基本清單，可幫助您確保 Prisma ORM 查詢達到最佳效能

• 將伺服器和資料庫託管在同一區域。
• 為您查詢中頻繁使用的列新增索引。
• 確保生產環境中至少有 3 個 CPU 核心可用。
• 在需要時測量效能並使用原始 SQL 最佳化查詢。
• 使用 Prisma ORM 的OpenTelemetry 跟蹤和指標功能監控您的查詢。
• 為您的資料庫新增快取層（例如Prisma Accelerate）。
• 如果您的應用程式是無伺服器的，請遵循無伺服器效能的最佳實踐。

如果您遵循了這些建議，但仍然看到慢速查詢，請在GitHub 上開一個 issue，並提供您的查詢詳細資訊，以便我們確保它達到應有的速度！

Prisma Optimize 提供的洞察和建議

為了支援您測量效能並加快 Prisma ORM 查詢速度，我們最近推出了Prisma Optimize。

Optimize 捕獲透過 Prisma ORM 傳送到資料庫的所有查詢，並透過詳細的跟蹤資訊為您提供其效能洞察。未來，Optimize 將能夠為您提供加快慢速查詢的建議，例如，當返回的行數過多或應在模式中定義索引時給出建議。

檢視基準測試結果

您可以在https://benchmarks.prisma.io上找到我們的基準測試結果。檢視它們，並在X和Discord上告訴我們您的想法。我們特別期待聽到您認為如何能使這個基準測試對您更有幫助，並歡迎改進建議！