Amazon Redshift 自 2025 年 11 月 1 日起不再支援建立新的 Python UDF。如果您想要使用 Python UDF,請在該日期之前建立 UDF。現有 Python UDF 將繼續正常運作。如需詳細資訊,請參閱部落格文章
本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Amazon Redshift Serverless 的帳單
運算容量的帳單
您可以透過兩種方式為 Amazon Redshift Serverless 購買容量:
您可以同時使用保留和隨需資源。您不必只選用其中之一。
如需詳細的定價資訊,請參閱 Amazon Redshift 定價
儲存的帳單
主要儲存容量會以 Redshift 受管儲存 (RMS) 來計費。儲存會按每月 GB 數計費。儲存帳單不同於運算容量帳單。視用量方案而定,用於使用者快照的儲存會以標準備份帳單費率計費。
資料傳輸成本和機器學習 (ML) 成本會分開收取,情況與佈建叢集相同。AWS區域間的快照複寫和資料共用會按照定價頁面上概述的傳輸速率計費。如需詳細資訊,請參閱 Amazon Redshift 定價
使用 CloudWatch 將帳單用量視覺化
系統會產生追蹤快照儲存用量的指標 SnapshotStorage,並將其傳送至 CloudWatch。如需 CloudWatch 的相關資訊,請參閱什麼是 Amazon CloudWatch?
使用 Amazon Redshift Serverless 免費試用
Amazon Redshift Serverless 會提供免費試用。如果您參與免費試用,便可在 Redshift 主控台中檢視免費試用額度餘額,並在 SYS_SERVERLESS_USAGE 系統檢視中查看免費試用用量。請注意,免費試用用量的帳單詳細資訊不會出現在帳單主控台中。免費試用結束後,您只能在帳單主控台中檢視用量。如需 Amazon Redshift Serverless 免費試用的相關資訊,請參閱 Amazon Redshift Serverless 免費試用
帳單用量注意事項
-
記錄用量 — 查詢或交易只會在交易完成、回復或停止後才進行計量和記錄。例如,如果交易執行兩天,系統便會在交易完成後記錄 RPU 用量。您可以透過查詢
sys_serverless_usage即時監控持續的使用情況。系統可能會以特定小時和每日使用的 RPU 用量變化和效果成本的形式來反映交易記錄。 -
寫入明確交易 — 請務必將結束交易作為最佳實務。如果您沒有結束或回復開啟的交易,Amazon Redshift Serverless 會繼續使用 RPU。例如,如果你寫入明確的
BEGIN TRAN,則務必要有相應的COMMIT和ROLLBACK陳述式。 -
已取消的查詢 — 如果您執行查詢並在查詢完成前將其取消,系統仍會就查詢執行過的時間向您收費。
-
擴展 — Amazon Redshift Serverless 執行個體可能會啟動擴展來處理負載較高的時段,以維持一致的效能。您的 Amazon Redshift Serverless 帳單包含相同 RPU 費率的基本運算容量和擴展的容量。
-
縮減規模 — Amazon Redshift Serverless 會從其基本 RPU 容量縱向擴展,以處理負載較高的時段。在某些情況下,RPU 容量可能會在查詢負載下降後於一段時間內保持較高的設定。建議您在主控台中設定 RPU 時數上限,以免產生意外成本。
-
系統資料表 — 當您查詢系統資料表時,系統會就查詢時間計費。
-
Redshift Spectrum — 當您有 Amazon Redshift Serverless 並執行查詢時,資料湖查詢不需要另外付費。對儲存在 Amazon S3 中的資料所進行的查詢,按交易時間計算的費用與查詢本機資料時相同。
-
聯合查詢 — 聯合查詢會以特定時間間隔內所使用的 RPU 來收費,方式與資料倉儲或資料湖上的查詢相同。
-
儲存 — 儲存會以每月 GB 數另外計費。
-
最低費用 — 最低費用為 60 秒的資源用量,以每秒為單位來計量。
-
快照帳單 — 快照帳單不會變更。系統會根據儲存來收費,並以每月 GB 費率計費。您可以免費地將資料倉儲還原到過去 24 小時內的特定時間點 (可達 30 分鐘的精細程度)。如需詳細資訊,請參閱 Amazon Redshift 定價
。
保持帳單可預測性的 Amazon Redshift Serverless 最佳實務
以下是有助於保持帳單一致性的最佳實務和內建設定。
-
確實結束每個交易。當您使用
BEGIN開始交易時,請務必也將其END。 -
使用最佳實務錯誤處理來適當地回應錯誤並結束每個交易。盡量減少開啟的交易有助於避免不必要的 RPU 用量。
-
使用
SESSION TIMEOUT來協助結束開啟的交易和閒置的工作階段。其會導致任何閒置或非作用中時間超過 3600 秒 (1 小時) 的工作階段逾時。其會導致任何保持開啟和非作用中狀態超過 21600 秒 (6 小時) 的交易逾時。您可以針對特定使用者明確變更此逾時設定,例如當您想要為長時間執行的查詢保持工作階段開啟狀態時。CREATE USER 主題會顯示如何調整使用者的SESSION TIMEOUT。-
在大多數情況下,建議您不要延長
SESSION TIMEOUT值,除非您有特別需要這麼做的使用案例。如果工作階段仍處於閒置狀態,具有開啟中的交易,則可能會導致系統使用 RPU,直到工作階段關閉為止。這會導致不必要的成本。 -
Amazon Redshift Serverless 的執行中查詢時間上限為 86,399 秒 (24 小時)。開啟中交易的非作用中期間上限為六小時,超過之後,Amazon Redshift Serverless 就會結束與交易相關聯的工作階段。如需詳細資訊,請參閱Amazon Redshift Serverless 物件的配額。
-
具有連線集區的 Amazon Redshift Serverless 帳單
Amazon Redshift Serverless 會將所有傳入查詢視為可計費使用者活動,包括連線集區傳送的輕量型運作狀態檢查查詢。無論查詢是來自應用程式、JDBC/ODBC 驅動器,還是連線集區架構,此行為都適用。每個運作狀態檢查查詢都會觸發運算用量,而且無論查詢用途或出處為何,都會產生費用。因此,即使沒有實際的使用者工作負載在執行,讓連線集區保持開啟仍會產生成本。
連線集區會在應用程式與 Amazon Redshift Serverless 端點之間維護持久的連線集區。為了確保這些連線保持正常運作且可用,集區機制通常會定期傳送輕量型或空的查詢 (例如 SELECT
1)。這些自動化查詢會驗證連線狀態。
當您使用連線集區時,請參考以下這些最佳實務,以盡可能減少產生意外的費用:
-
藉由檢閱和最佳化連線集區組態中的運作狀態檢查或保持連線查詢的頻率,以調整運作狀態檢查頻率。
-
藉由設定連線集區來最佳化閒置系統設定,以盡可能減少系統閒置期間不必要的連線流失或背景查詢活動。
-
實作可減少開銷的應用程式層級集區或更有效率的連線生命週期管理。
-
如果您的連線集區組態允許的話,請停用活動訊號或驗證查詢。查看您特定的連線字串參數或組態檔案,以調整這些設定。
-
微調 TCP 保持連線設定:如果您無法停用驅動器的內部活動訊號機制,請在作業系統或應用程式層級調整傳輸控制通訊協定 (TCP) 保持連線設定,以解決連線逾時問題。如需詳細資訊,請參閱您的作業系統、JDBC/ODBC 驅動器或連線集區文件。
-
最佳化資料庫連線集區:設定您的連線集區 (HikariCP、Apache Database Connection Pool),以管理連線並盡可能降低連線的額外負荷。專注於參數,例如最大連線數、閒置逾時和驗證查詢 (如有需要)。此最佳化有助於使 Amazon Redshift Serverless 運算用量與實際工作負載需求保持一致,進而可能降低成本。
採用零 ETL 的 Amazon Redshift Serverless 成本最佳化
若要在 Amazon Redshift Serverless 上執行零 ETL 整合時最佳化成本,您可以最適化調整環境,並根據工作負載需求調整重新整理設定。請考慮進行下列調整:
-
使用適用於工作負載的 8 個 RPU 較低基本 RPU 容量。
-
設定目標 Redshift 執行個體的 REFRESH_INTERVAL,以平衡最新狀態與成本。較短的間隔可確保近乎即時的更新,但會增加運算成本。較長的間隔 (5 分鐘或更長) 可減少不需即時保持最新狀態的工作負載費用,例如報告或歷史分析。若要編輯 Redshift 目標 REFRESH_INTERVAL,請參閱 ALTER DATABASE 描述中的重新整理間隔子句。
-
藉由並行執行分析工作負載,同時擷取零 ETL 資料的方式,充分利用 Amazon Redshift Serverless 環境。這可確保運算容量主動提供給多種業務用途。