# 从 PostgreSQL 迁移到 Aurora DSQL
<a name="working-with-postgresql-compatibility-migration-guide"></a>

Aurora DSQL 设计为[与 PostgreSQL 兼容](working-with-postgresql-compatibility.md)，支持诸如 ACID 事务、辅助索引、联接和标准 DML 操作等核心关系功能。大多数现有 PostgreSQL 应用程序只需进行极少的更改，即可迁移到 Aurora DSQL。

本节提供将应用程序迁移到 Aurora DSQL 的实用指南，包括框架兼容性、迁移模式和架构注意事项。

## 框架和 ORM 兼容性
<a name="dsql-framework-compatibility"></a>

 Aurora DSQL 使用标准 PostgreSQL 线路协议，同时确保与 PostgreSQL 驱动程序和框架的兼容性。大多数流行的 ORM 与 Aurora DSQL 一起工作，而只需进行极少的更改或不需要更改。有关参考实现和可用的 ORM 集成，请参阅 [Aurora DSQL 适配器和方言](aws-sdks.md#aurora-dsql-adapters)。

## 常见迁移模式
<a name="working-with-postgresql-compatibility-migration-considerations"></a>

 从 PostgreSQL 迁移到 Aurora DSQL 时，某些功能的工作原理会有所不同或具有其它语法。本节提供有关常见迁移场景的指导。

### DDL 操作替代方案
<a name="dsql-ddl-alternatives"></a>

Aurora DSQL 为传统的 PostgreSQL DDL 操作提供了现代替代方案：

**索引创建**  
使用 `CREATE INDEX ASYNC` 而非 `CREATE INDEX` 来创建非阻止索引。  
**优势：**在大型表上创建零停机时间索引。

**数据移除**  
使用 `DELETE FROM table_name`，而不使用 `TRUNCATE`。  
**替代方案：**要完全重新创建表，请使用 `DROP TABLE`，后跟 `CREATE TABLE`。

**系统配置**  
Aurora DSQL 是完全托管式的，因此，配置是根据工作负载模式自动处理的。使用 AWS 管理控制台或 API 来管理集群设置。  
**优点：**无需进行数据库调整或参数管理。

### 架构设计模式
<a name="dsql-schema-design-patterns"></a>

调整以下常见的 PostgreSQL 模式以实现 Aurora DSQL 兼容性：

**引用完整性模式**  
Aurora DSQL 支持表关系和 `JOIN` 操作。为实现引用完整性，请在应用程序层中实现验证。这种设计与现代分布式数据库模式保持一致，在这种模式中，应用程序层验证可提供更大的灵活性，并可避免级联操作带来的性能瓶颈。  
**模式：**使用一致的命名约定、验证逻辑和事务边界，在应用程序层中实施引用完整性检查。许多大规模应用程序更喜欢这种方法，以便更好地控制错误处理和性能。

**临时数据处理**  
使用带有清理逻辑的 CTE、子查询或常规表，而不是临时表。  
**替代方案：**使用会话特定的名称创建表，然后在应用程序中对其进行清理。

## 了解架构差异
<a name="working-with-postgresql-compatibility-architectural-differences"></a>

Aurora DSQL 的分布式无服务器架构在若干方面有意与传统 PostgreSQL 有所不同。这些差异使 Aurora DSQL 具有简单性和可扩展性等主要优势。

### 简化的数据库模型
<a name="dsql-simplified-database-model"></a>

**每个集群单个数据库**  
Aurora DSQL 为每个集群提供一个名为 `postgres` 的内置数据库。  
**迁移提示：**如果应用程序使用多个数据库，请创建单独的 Aurora DSQL 集群来进行逻辑分离，或者在单个集群中使用架构。

**无临时表**  
 对于临时数据处理，应使用公用表表达式（CTE）和子查询，它们可为复杂查询提供灵活的替代方案。  
 **替代方案：**将带有 `WITH` 子句的 CTE 用于临时结果集，或者使用带有唯一命名的常规表来存储会话特定的数据。

**自动存储管理**  
Aurora DSQL 消除了表空间和手动存储管理。存储空间会根据数据模式自动扩展和优化。  
**优势：**无需监控磁盘空间、规划存储分配或管理表空间配置。

### 现代应用程序模式
<a name="dsql-modern-application-patterns"></a>

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 ` 操作。为实现引用完整性，请在应用程序层中实现验证。尽管强制执行引用完整性可能很有价值，但级联操作（如级联删除）可能会造成意想不到的性能问题，例如，删除包含 1000 个订单项的订单会变成一个 1001 行的事务。出于这个原因，许多客户避免使用外键限制。  
**设计模式：**在应用程序层中实施引用完整性检查，使用最终一致性模式，或利用 AWS 服务进行数据验证。

### 操作简化
<a name="dsql-operational-simplifications"></a>

Aurora DSQL 消除了许多传统的数据库维护任务，从而减少了操作开销：

**无需手动维护**  
Aurora DSQL 自动管理存储优化、统计数据收集和性能调整。诸如 `VACUUM` 等传统维护命令由系统处理。  
**优点：**不需要数据库维护时段、vacuum 调度和系统参数调整。

**自动分区和扩展**  
Aurora DSQL 会根据访问模式自动对您的数据进行分区和分配。使用 UUID 或应用程序生成的 ID，以实现最佳分配。  
**迁移提示：**移除手动分区逻辑，让 Aurora DSQL 处理数据分配。使用 UUID 或应用程序生成的 ID，以实现最佳分配。如果您的应用程序需要序列标识符，请参阅[序列和标识列](sequences-identity-columns.md)。

## Aurora DSQL 有关 PostgreSQL 兼容性的注意事项
<a name="working-with-postgresql-compatibility-unsupported-limitations"></a>

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 语句
  + 一个事务最多可以修改 3000 行，而无论二级索引的数量如何
  + 3000 行的限制适用于所有 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)。

## 需要迁移方面的帮助吗？
<a name="dsql-migration-feedback-link"></a>

如果您遇到对迁移至关重要但 Aurora DSQL 目前不支持的功能，请参阅[提供有关 Amazon Aurora DSQL 的反馈](providing-feedback.md)，以了解有关如何与 AWS 分享反馈的信息。