从 PostgreSQL 迁移到 Aurora DSQL

使用 CREATE INDEX ASYNC 而非 CREATE INDEX 来创建非阻止索引。

优势：在大型表上创建零停机时间索引。

使用 DELETE FROM table_name，而不使用 TRUNCATE。

替代方案：要完全重新创建表，请使用 DROP TABLE，后跟 CREATE TABLE。

Aurora DSQL 是完全托管式的，因此，配置是根据工作负载模式自动处理的。使用 AWS 管理控制台或 API 来管理集群设置。

优点：无需进行数据库调整或参数管理。

Aurora DSQL 支持表关系和 JOIN 操作。为实现引用完整性，请在应用程序层中实现验证。这种设计与现代分布式数据库模式保持一致，在这种模式中，应用程序层验证可提供更大的灵活性，并可避免级联操作带来的性能瓶颈。

模式：使用一致的命名约定、验证逻辑和事务边界，在应用程序层中实施引用完整性检查。许多大规模应用程序更喜欢这种方法，以便更好地控制错误处理和性能。

使用带有清理逻辑的 CTE、子查询或常规表，而不是临时表。

替代方案：使用会话特定的名称创建表，然后在应用程序中对其进行清理。

Aurora DSQL 为每个集群提供一个名为 postgres 的内置数据库。

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

对于临时数据处理，应使用公用表表达式（CTE）和子查询，它们可为复杂查询提供灵活的替代方案。

替代方案：将带有 WITH 子句的 CTE 用于临时结果集，或者使用带有唯一命名的常规表来存储会话特定的数据。

Aurora DSQL 消除了表空间和手动存储管理。存储空间会根据数据模式自动扩展和优化。

优势：无需监控磁盘空间、规划存储分配或管理表空间配置。

要获得类似触发器的功能，请在应用程序层中实现事件驱动的逻辑。

迁移策略：将触发逻辑移至应用程序代码，将事件驱动架构与 EventBridge 等 AWS 服务结合使用，或者使用应用程序日志记录来实现审计跟踪记录。

Aurora DSQL 支持基于 SQL 的函数，但不支持像 PL/pgSQL 这样的程序性语言。

替代方案：使用 SQL 函数进行数据转换，或者将复杂逻辑移至应用程序层或 AWS Lambda 函数。

Aurora DSQL 使用乐观并发控制（OCC），这是一种不同于传统数据库锁定机制的无锁方法。Aurora DSQL 不是获取用于阻止其它事务的锁，而是支持事务在不阻止的情况下继续进行，并在提交时检测冲突。这样可以消除死锁，并防止慢速事务阻止其它操作。

主要区别：发生冲突时，Aurora DSQL 返回序列化错误，而不是让事务等待锁定。这要求应用程序实现重试逻辑，类似于处理传统数据库中的锁定超时，但冲突可以立即得到解决，而不是导致阻止等待。

设计模式：使用重试机制实现幂等事务逻辑。设计架构，通过使用随机主键并在键范围内分布更新，最大限度地减少争用。有关更多信息，请参阅 Aurora DSQL 中的并发控制。

Aurora DSQL 支持表之间的外键关系，包括 JOIN 操作。为实现引用完整性，请在应用程序层中实现验证。尽管强制执行引用完整性可能很有价值，但级联操作（如级联删除）可能会造成意想不到的性能问题，例如，删除包含 1000 个订单项的订单会变成一个 1001 行的事务。出于这个原因，许多客户避免使用外键限制。

设计模式：在应用程序层中实施引用完整性检查，使用最终一致性模式，或利用 AWS 服务进行数据验证。

Aurora DSQL 自动管理存储优化、统计数据收集和性能调整。诸如 VACUUM 等传统维护命令由系统处理。

优点：不需要数据库维护时段、vacuum 调度和系统参数调整。

Aurora DSQL 会根据访问模式自动对您的数据进行分区和分配。使用 UUID 或应用程序生成的 ID，以实现最佳分配。

迁移提示：移除手动分区逻辑，让 Aurora DSQL 处理数据分配。使用 UUID 或应用程序生成的 ID，以实现最佳分配。如果您的应用程序需要序列标识符，请参阅序列和标识列。