你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 Azure Database for PostgreSQL 单一服务器构建应用程序的最佳做法

项目
04/03/2023

适用于：Azure Database for PostgreSQL 单一服务器

重要

Azure Database for PostgreSQL - 单一服务器即将停用。我们强烈建议升级到 Azure Database for PostgreSQL 灵活服务器。若要详细了解如何迁移到 Azure Database for PostgreSQL 灵活服务器，请参阅 Azure Database for PostgreSQL 单一服务器的最新动态。

下面是一些可帮助你使用 Azure Database for PostgreSQL 构建云就绪应用程序的最佳做法。这些最佳做法可以减少应用开发时间。

应用程序和数据库资源的配置

使应用程序和数据库位于同一区域中

在 Azure 中部署应用程序时，请确保所有依赖项都位于同一区域中。跨区域或可用性区域分布实例会造成网络延迟，这可能会影响应用程序的总体性能。

确保 PostgreSQL 服务器的安全

将 PostgreSQL 服务器配置为安全且不能公开访问的服务器。使用以下选项之一来保护服务器：

为了安全起见，必须始终通过 SSL 连接到 PostgreSQL 服务器，并将 PostgreSQL 服务器和应用程序配置为使用 TLS 1.2。了解如何配置 SSL/TLS。

使用环境变量获取连接信息

不要在应用程序代码中保存数据库凭据。根据前端应用程序按指南来设置环境变量。有关应用服务的使用，请参阅如何配置应用设置；有关 Azure Kubernetes 服务，请参阅如何使用 Kubernetes 机密。

性能和复原能力

下面是一些可以用来帮助调试应用程序性能问题的工具和做法。

使用连接池

使用连接池，在启动时建立一组固定的连接并进行维护。这还有助于减少由于在数据库服务器上建立动态新连接而导致的服务器上的内存碎片。如果应用框架或数据库驱动程序支持连接池，则可以在应用程序端对其进行配置。如果不支持这种情况，另一种建议的方法是利用代理连接池程序服务，如在应用程序外部运行并连接到数据库服务器的 PgBouncer 或 Pgpool。 PgBouncer 和 Pgpool 都是基于社区的工具，可用于 Azure Database for PostgreSQL。

用来处理暂时性错误的重试逻辑

你的应用程序可能会遇到暂时性错误：到数据库的连接间歇性断开或丢失。在这种情况下，服务器在 5 到 10 秒内重试一两次后就会启动并运行。良好的做法是在第一次重试前等待 5 秒。然后，每次重试都逐步延长等待时间，最多 60 秒。限制最大重试次数。达到该次数时，应用程序会认为操作失败，随后你就可以进一步进行调查。有关详细信息，请参阅如何排查连接错误。

启用读取复制以缓解故障转移问题

对于故障转移场景，可以使用数据传入复制。使用只读副本时，在源服务器与副本服务器之间无法自动进行故障转移。由于复制是异步的，因此你会注意到在源服务器与副本之间存在延迟。网络延迟可能受许多因素影响，例如，在源服务器上运行的工作负荷的大小，以及数据中心之间的延迟。大多数情况下，副本延迟在几秒钟到几分钟之间。

数据库部署

配置 CI/CD 部署管道

有时，你需要将更改部署到数据库。在这种情况下，可以通过 GitHub Actions 使用持续集成 (CI)，使 PostgreSQL 服务器可通过对其运行自定义脚本来更新数据库。

定义手动数据库部署过程

在手动部署数据库的过程中，请执行以下步骤以最大程度地减少停机时间或降低部署失败的风险：

使用 pg_dump，在新数据库上创建生产数据库的副本。
使用数据库所需的新架构更改或更新来更新新数据库。
将生产数据库置于只读状态。在部署完成之前，不应当对生产数据库执行写入操作。
使用步骤 1 中新更新的数据库测试你的应用程序。
部署你的应用程序更改，并确保应用程序目前正在使用具有最新更新的新数据库。
保留旧的生产数据库，以便回滚更改。然后，你可以评估是删除旧的生产数据库，还是根据需要将其导出到 Azure 存储。

注意

如果应用程序类似于电子商务应用，并且不能将其置于只读状态，请在进行备份后直接在生产数据库上部署更改。这些更改应在非高峰时间（此时发往应用的流量较小）进行，以最大程度地降低影响，因为某些用户可能会遇到请求失败的情况。请确保应用程序代码还处理所有失败的请求。

数据库架构和查询

下面是构建数据库架构和查询时需要注意的一些技巧。

将 BIGINT 或 UUID 用作主键

在构建自定义应用程序或某些框架时，它们可能将 INT 而不是 BIGINT 用作主键。使用 INT 时，存在数据库中的值超出 INT 数据类型的存储容量的风险。对现有生产应用程序进行此更改可能会花费更多的开发时间。另一种方法是将 UUID 用作主键。此标识符使用自动生成的 128 位字符串，例如 a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11。详细了解 PostgreSQL 数据类型。

使用索引

Postgres 中有多种类型的索引，可通过不同方式使用。使用索引时服务器查找和检索特定行的速度比不使用索引时快。但索引也会增加数据库服务器的开销，因此应避免使用过多索引。

使用 autovacuum

可以在 Azure Database for PostgreSQL 服务器上使用 autovacuum 优化服务器。 PostgreSQL 支持更好的数据库并发，但每次更新都会导致插入和删除。对于删除，记录将被软标记，稍后被清除。为执行这些任务，PostgreSQL 将运行一个清扫作业。如果不时常运行清扫作业，累积的死元组可能会导致以下问题：

数据膨胀，例如数据库和表变大。
更大的非最优索引。
I/O 增加。

详细了解如何使用 autovacuum 进行优化。

使用 pg_stats_statements

Pg_stat_statements 是 PostgreSQL 扩展，默认情况下在 Azure Database for PostgreSQL 中启用。该扩展提供了一种方法来跟踪服务器执行的所有 SQL 语句的执行统计信息。请参阅如何使用 pg_statement。

使用查询存储

Azure Database for PostgreSQL 中的查询存储功能提供了用于跟踪查询统计信息的一种方法。建议使用此功能作为使用 pg_stats_statements 的替代方法。

优化批量插入并使用临时数据

如果工作负荷操作涉及到瞬态数据或者需要批量插入大型数据集，可以考虑使用无日志记录表。它在默认情况下提供原子性和持久性。原子性、一致性、隔离性和持久性组成了 ACID 属性。请参阅如何优化批量插入。