從 PostgreSQL 遷移至 Aurora DSQL

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

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

使用 DELETE FROM table_name而非 TRUNCATE。

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

Aurora DSQL 不支援 ALTER SYSTEM 命令，因為系統完全受管。組態會根據工作負載模式自動處理。

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

使用 UUIDs或複合索引鍵，而非自動遞增序列。自動遞增序列會導致分散式系統中發生大量衝突，因為多個寫入器正在嘗試更新相同的資料。UUIDs提供相同的函數，但不需要協調。

範例：id UUID PRIMARY KEY DEFAULT gen_random_uuid()

Aurora DSQL 支援資料表關係和JOIN操作，但尚未強制執行外部金鑰限制。此設計選擇符合現代分散式資料庫模式，其中應用程式層驗證提供更多彈性，並避免層疊操作造成效能瓶頸。

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

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

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

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

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

Aurora DSQL 尚未支援暫時資料表。常見的資料表表達式 (CTEs) 和子查詢可以用作複雜查詢的替代方案。

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

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

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

Aurora DSQL 不支援觸發。

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

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

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

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

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

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

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

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

Aurora DSQL 不需要 VACUUM、 TRUNCATE或 ALTER SYSTEM命令。系統會自動管理儲存最佳化、統計資料收集和效能調校。

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

Aurora DSQL 會根據存取模式自動分割和分配您的資料。不需要手動分割和序列。

遷移秘訣：移除手動分割邏輯，並讓 Aurora DSQL 處理資料分佈。使用 UUIDs 或應用程式產生的 IDs，而非序列。