從 PostgreSQL 遷移至 Aurora DSQL

使用 CREATE INDEX ASYNC而非 CREATE INDEX 建立非封鎖索引。

優點：在大型資料表上建立零停機時間索引。

使用 DELETE FROM table_name而非 TRUNCATE。

替代方案：若要完成資料表重新建立，請使用 DROP TABLE，後面接著 CREATE TABLE。

Aurora DSQL 是全受管的，因此會根據工作負載模式自動處理組態。使用 AWS 管理主控台或 API 來管理叢集設定。

優點：不需要進行資料庫調校或參數管理。

Aurora DSQL 支援資料表關係和JOIN操作。如需參考完整性，請在應用程式層中實作驗證。此設計符合現代分散式資料庫模式，其中應用程式層驗證提供更多彈性，並避免層疊操作造成效能瓶頸。

模式：使用一致的命名慣例、驗證邏輯和交易界限，在您的應用程式層中實作參考完整性檢查。許多大規模應用程式偏好這種方法來更好地控制錯誤處理和效能。

使用具有清除邏輯CTEs、子查詢或一般資料表，而非暫存資料表。

替代方案：建立具有工作階段特定名稱的資料表，並在應用程式中清除它們。

Aurora DSQL postgres為每個叢集提供一個名為 的內建資料庫。

遷移秘訣：如果您的應用程式使用多個資料庫，請建立個別的 Aurora DSQL 叢集進行邏輯分離，或在單一叢集中使用結構描述。

對於臨時資料處理，您應該使用常見的資料表表達式 (CTEs) 和子查詢，為複雜的查詢提供靈活的替代方案。

替代方案：將 CTEs與暫時結果集的 WITH子句搭配使用，或使用工作階段特定資料的唯一命名規則資料表。

Aurora DSQL 消除了資料表空間和手動儲存管理。儲存會自動根據您的資料模式進行擴展和最佳化。

優點：不需要監控磁碟空間、規劃儲存配置或管理資料表空間組態。

如需類似觸發的功能，請在應用程式層中實作事件驅動的邏輯。

遷移策略：將觸發邏輯移至應用程式程式碼、搭配 EventBridge 等 AWS 服務使用事件驅動型架構，或使用應用程式記錄實作稽核線索。

Aurora DSQL 支援以 SQL 為基礎的函數，但不支援程序語言，例如 PL/pgSQL。

替代方案：使用 SQL 函數進行資料轉換，或將複雜的邏輯移至您的應用程式層或 AWS Lambda 函數。

Aurora DSQL 使用樂觀並行控制 (OCC)，這是一種與傳統資料庫鎖定機制不同的無鎖定方法。Aurora DSQL 不會取得封鎖其他交易的鎖定，而是允許交易繼續進行，而不會封鎖和偵測遞交時的衝突。這可消除死結，並防止慢速交易封鎖其他操作。

關鍵差異：發生衝突時，Aurora DSQL 會傳回序列化錯誤，而不是讓交易等待鎖定。這需要應用程式實作重試邏輯，類似於處理傳統資料庫中的鎖定逾時，但衝突會立即解決，而不是導致封鎖等待。

設計模式：使用重試機制實作等冪交易邏輯。設計結構描述，透過使用隨機主索引鍵並將更新分散到您的索引鍵範圍，將爭用降至最低。如需詳細資訊，請參閱Aurora DSQL 的並行控制。

Aurora DSQL 支援資料表之間的外部金鑰關係，包括 JOIN 操作。如需參考完整性，請在應用程式層中實作驗證。雖然強制執行參考完整性可能很有價值，但串聯操作 （例如串聯刪除） 可能會產生非預期的效能問題，例如，刪除具有 1，000 個明細項目的訂單會變成 1，001 列交易。因此，許多客戶會避免外部金鑰限制。

設計模式：在您的應用程式層中實作參考完整性檢查、使用最終一致性模式，或利用 AWS 服務進行資料驗證。

Aurora DSQL 會自動管理儲存最佳化、統計資料收集和效能調校。這類傳統維護命令由系統VACUUM處理。

優點：無需進行資料庫維護時段、清空排程和系統參數調校。

Aurora DSQL 會根據存取模式自動分割和分配您的資料。使用 UUIDs或應用程式產生的 IDs以獲得最佳分佈。

遷移秘訣：移除手動分割邏輯，並讓 Aurora DSQL 處理資料分佈。使用 UUIDs或應用程式產生的 IDs以獲得最佳分佈。如果您的應用程式需要循序識別符，請參閱 序列和身分資料欄。