本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 從 PostgreSQL 遷移至 Aurora DSQL
Aurora DSQL 的設計與 [PostgreSQL 相容](working-with-postgresql-compatibility.md)，支援 ACID 交易、次要索引、聯結和標準 DML 操作等核心關聯式功能。大多數現有的 PostgreSQL 應用程式都可以遷移至 Aurora DSQL，且變更最少。
本節提供將應用程式遷移至 Aurora DSQL 的實際指導，包括架構相容性、遷移模式和架構考量。
## 架構和 ORM 相容性
Aurora DSQL 使用標準 PostgreSQL 線路通訊協定，以確保與 PostgreSQL 驅動程式和架構的相容性。最熱門ORMs 可搭配 Aurora DSQL 使用，但幾乎沒有變更。如需參考實作和可用的 ORM 整合[Aurora DSQL 轉接器和方言](aws-sdks.md#aurora-dsql-adapters)，請參閱 。
## 常見的遷移模式
從 PostgreSQL 遷移到 Aurora DSQL 時，某些功能的運作方式不同，或有其他語法。本節提供常見遷移案例的指引。
### DDL 操作替代方案
Aurora DSQL 提供傳統 PostgreSQL DDL 操作的現代替代方案：
**建立索引**
使用 `CREATE INDEX ASYNC`而非 `CREATE INDEX` 建立非封鎖索引。
**優點：**在大型資料表上建立零停機時間索引。
**資料移除**
使用 `DELETE FROM table_name`而非 `TRUNCATE`。
**替代方案：**若要完成資料表重新建立，請使用 `DROP TABLE`，後面接著 `CREATE TABLE`。
**系統組態**
Aurora DSQL 是全受管的，因此會根據工作負載模式自動處理組態。使用 AWS 管理主控台或 API 來管理叢集設定。
**優點：**不需要進行資料庫調校或參數管理。
### 結構描述設計模式
為 Aurora DSQL 相容性調整這些常見的 PostgreSQL 模式：
**參考完整性模式**
Aurora DSQL 支援資料表關係和`JOIN`操作。如需參考完整性，請在應用程式層中實作驗證。此設計符合現代分散式資料庫模式，其中應用程式層驗證提供更多彈性，並避免層疊操作造成效能瓶頸。
**模式：**使用一致的命名慣例、驗證邏輯和交易界限，在您的應用程式層中實作參考完整性檢查。許多大規模應用程式偏好這種方法來更好地控制錯誤處理和效能。
**暫時資料處理**
使用具有清除邏輯CTEs、子查詢或一般資料表，而非暫存資料表。
**替代方案：**建立具有工作階段特定名稱的資料表，並在應用程式中清除它們。
## 了解架構差異
Aurora DSQL 的分散式無伺服器架構刻意在數個區域與傳統 PostgreSQL 不同。這些差異可實現 Aurora DSQL 簡化和擴展的主要優勢。
### 簡化的資料庫模型
**每個叢集的單一資料庫**
Aurora DSQL `postgres`為每個叢集提供一個名為 的內建資料庫。
**遷移秘訣：**如果您的應用程式使用多個資料庫，請建立個別的 Aurora DSQL 叢集進行邏輯分離，或在單一叢集中使用結構描述。
**沒有暫存資料表**
對於臨時資料處理，您應該使用通用資料表表達式 (CTEs) 和子查詢，為複雜的查詢提供靈活的替代方案。
**替代方案：**將 CTEs與暫時結果集的 `WITH`子句搭配使用，或使用工作階段特定資料的唯一命名規則資料表。
**自動儲存管理**
Aurora DSQL 消除了資料表空間和手動儲存管理。儲存會根據您的資料模式自動擴展和最佳化。
**優點：**不需要監控磁碟空間、規劃儲存配置或管理資料表空間組態。
### 現代應用程式模式
Aurora DSQL 鼓勵現代應用程式開發模式，以改善可維護性和效能：
**應用程式層級邏輯而非資料庫觸發**
如需類似觸發的功能，請在應用程式層中實作事件驅動的邏輯。
**遷移策略：**將觸發邏輯移至應用程式程式碼、搭配 EventBridge 等 AWS 服務使用事件驅動型架構，或使用應用程式記錄實作稽核線索。
**資料處理的 SQL 函數**
Aurora DSQL 支援以 SQL 為基礎的函數，但不支援程序語言，例如 PL/pgSQL。
**替代方案：**使用 SQL 函數進行資料轉換，或將複雜的邏輯移至您的應用程式層或 AWS Lambda 函數。
**樂觀並行控制而非冪等鎖定**
Aurora DSQL 使用樂觀並行控制 (OCC)，這是一種與傳統資料庫鎖定機制不同的無鎖定方法。Aurora DSQL 不會取得封鎖其他交易的鎖定，而是允許交易繼續進行，而不會封鎖和偵測遞交時的衝突。這可消除死結，並防止慢速交易封鎖其他操作。
**關鍵差異：**發生衝突時，Aurora DSQL 會傳回序列化錯誤，而不是讓交易等待鎖定。這需要應用程式實作重試邏輯，類似於處理傳統資料庫中的鎖定逾時，但衝突會立即解決，而不是導致封鎖等待。
**設計模式：**使用重試機制實作等冪交易邏輯。設計結構描述，透過使用隨機主索引鍵並將更新分散到您的索引鍵範圍，將爭用降至最低。如需詳細資訊，請參閱[Aurora DSQL 的並行控制](working-with-concurrency-control.md)。
**關係和參考完整性**
Aurora DSQL 支援資料表之間的外部金鑰關係，包括 ` JOIN ` 操作。如需參考完整性，請在應用程式層中實作驗證。雖然強制執行參考完整性可能很有價值，但串聯操作 （例如串聯刪除） 可能會產生非預期的效能問題，例如，刪除具有 1，000 個明細項目的訂單會變成 1，001 列交易。因此，許多客戶會避免外部金鑰限制。
**設計模式：**在您的應用程式層中實作參考完整性檢查、使用最終一致性模式，或利用 AWS 服務進行資料驗證。
### 操作簡化
Aurora DSQL 可消除許多傳統資料庫維護任務，減少營運開銷：
**不需要手動維護**
Aurora DSQL 會自動管理儲存最佳化、統計資料收集和效能調校。這類傳統維護命令由系統`VACUUM`處理。
**優點：**不需要資料庫維護時段、清空排程和系統參數調校。
**自動分割和擴展**
Aurora DSQL 會根據存取模式自動分割和分配您的資料。使用 UUIDs或應用程式產生的 IDs以獲得最佳分佈。
**遷移秘訣：**移除手動分割邏輯，並讓 Aurora DSQL 處理資料分佈。使用 UUIDs或應用程式產生的 IDs以獲得最佳分佈。如果您的應用程式需要循序識別符，請參閱 [序列和身分資料欄](sequences-identity-columns.md)。
# 使用 AI 工具進行代理遷移
AI 編碼代理器可以透過分析結構描述、轉換程式碼，以及使用內建安全檢查執行 DDL 遷移，加速遷移至 Aurora DSQL。
## 使用 Kiro 進行遷移
[Kiro](https://kiro.dev/) 等編碼代理程式可協助您分析並將 PostgreSQL 程式碼遷移至 Aurora DSQL：
+ **結構描述分析：**上傳現有的結構描述檔案，並要求 Kiro 識別潛在的相容性問題，並建議替代方案
+ **程式碼轉換：**提供您的應用程式程式碼，並要求 Kiro 協助重構觸發邏輯、以 UUIDs取代序列，或修改交易模式
+ **遷移規劃：**請 Kiro 根據您的特定應用程式架構建立step-by-step遷移計畫
+ **DDL 遷移：**使用具有內建安全檢查和使用者驗證的資料表重建模式來執行結構描述修改
**範例提示：**
```
"Analyze this PostgreSQL schema for DSQL compatibility and suggest alternatives for any unsupported features"
"Help me refactor this trigger function into application-level logic for DSQL migration"
"Create a migration checklist for moving my Django application from PostgreSQL to DSQL"
"Drop the legacy_status column from the orders table"
"Change the price column from VARCHAR to DECIMAL in the products table"
```
## 使用資料表重新建立進行 DDL 遷移
搭配 Aurora DSQL MCP 伺服器使用 AI 代理器時，某些 ALTER TABLE 操作會使用可安全遷移資料的*資料表重建模式*。代理程式會處理複雜性，同時在每個步驟通知您。
下列操作使用資料表重新建立模式：
| 作業 | 方法 |
| --- | --- |
| DROP COLUMN | 從新資料表中排除資料欄 |
| ALTER COLUMN TYPE | 在遷移期間投射資料類型 |
| ALTER COLUMN SET/DROP NOT NULL | 變更新資料表定義的限制條件 |
| ALTER COLUMN SET/DROP DEFAULT | 在新資料表定義中定義預設值 |
| ADD/DROP CONSTRAINT | 在新資料表中包含或移除限制條件 |
| MODIFY PRIMARY KEY | 使用唯一性驗證定義新的 PK |
| 分割/合併資料欄 | 使用 SPLIT\$1PART、SUBSTRING 或 CONCAT |
無需重新建立資料表，即可直接支援下列 ALTER TABLE 操作：
+ `ALTER TABLE ... RENAME COLUMN` – 重新命名資料欄
+ `ALTER TABLE ... RENAME TO` – 重新命名資料表
+ `ALTER TABLE ... ADD COLUMN` – 新增資料欄
**安全功能：**執行 DDL 遷移時，AI 代理器會呈現遷移計畫、驗證資料相容性、確認資料列計數，並在 DROP TABLE 等任何破壞性操作之前請求明確核准。
**批次遷移：**對於超過 3，000 個資料列的資料表，代理程式會自動以 500-1，000 個資料列的增量批次遷移，以保持在交易限制內。
## Aurora DSQL MCP 伺服器
Aurora DSQL 模型內容通訊協定 (MCP) 伺服器可讓 AI 助理直接連線至您的 Aurora DSQL 叢集，並搜尋 Aurora DSQL 文件。這可讓 AI：
+ 分析現有的結構描述並建議遷移變更
+ 使用資料表重新建立模式執行 DDL 遷移
+ 在遷移期間測試查詢並驗證相容性
+ 根據最新的 Aurora DSQL 文件提供準確up-to-date指引
若要搭配 AI 助理使用 Aurora DSQL MCP 伺服器，請參閱 [ Aurora DSQL MCP 伺服器的](SECTION_aurora-dsql-mcp-server.md)設定說明。
## Aurora DSQL 的 PostgreSQL 相容性考量
Aurora DSQL 具有與自我管理 PostgreSQL 不同的功能，可啟用其分散式架構、無伺服器操作和自動擴展。大多數應用程式會在這些差異中運作，無需修改。
如需一般考量，請參閱 [使用 Amazon Aurora DSQL 的考量事項](considerations.md)。如需了解配額和限制，請參閱 [Amazon Aurora DSQL 中的叢集配額與資料庫限制](CHAP_quotas.md)。
+ Aurora DSQL `postgres`使用每個叢集名為 的單一內建資料庫。對於邏輯分離，請建立個別的 Aurora DSQL 叢集，或在單一叢集中使用結構描述。
+ `postgres` 資料庫使用 UTF-8 字元編碼，可提供廣泛的國際字元支援。
+ 資料庫只會使用 `C` 定序。
+ Aurora DSQL 以 `UTC` 作為系統時區。Postgres 會將所有時區感知日期和時間儲存在 UTC 內部。您可以設定`TimeZone`組態參數來轉換用戶端的顯示方式，並做為伺服器將用來在內部轉換為 UTC 的用戶端輸入預設值。
+ 交易隔離層級固定為 PostgreSQL `Repeatable Read`。
+ 交易有下列限制：
+ DDL 和 DML 操作需要個別的交易
+ 交易只能包含 1 個 DDL 陳述式
+ 無論次要索引的數量為何，交易最多可以修改 3,000 個資料列
+ 3,000 個資料列的限制適用於所有 DML 陳述式 (`INSERT`、`UPDATE`、`DELETE`)
+ 資料庫連線會在 1 小時後逾時。
+ Aurora DSQL 透過結構描述層級授予來管理許可。管理員使用者使用 建立結構描述`CREATE SCHEMA`，並使用 授予存取權`GRANT USAGE ON SCHEMA`。管理員使用者管理公有結構描述中的物件，而非管理員使用者則在使用者建立的結構描述中建立物件，以實現明確的擁有權界限。如需詳細資訊，請參閱[授權資料庫角色在您的資料庫使用 SQL](using-database-and-iam-roles.md#using-database-and-iam-roles-custom-database-roles-sql)。
## 需要遷移協助嗎？
如果您遇到對遷移至關重要但 Aurora DSQL 目前不支援的功能，請參閱 以了解如何與 AWS 共用意見回饋[提供有關 Amazon Aurora DSQL 的意見回饋](providing-feedback.md)的相關資訊。