PostgreSQL 拥有超过 35 年的历史，在开源社区中拥有强大的追随者，被用于各种应用程序。随着 OCI 的不断发展，我们的客户要求我们支持 PostgreSQL。现在，我们很高兴地宣布 OCI Database with PostgreSQL版本 14.9全面可用。这一新增功能补充了我们现有的OCI 开源产品阵容，包括OCI Cache with Redis、OCI Search with OpenSearch和MySQL HeatWave。
对于希望在云中轻松扩展且无需更改应用程序的组织来说，OCI Database with PostgreSQL数据库是理想的解决方案。它提供完全的 PostgreSQL 兼容性，同时让用户利用 OCI 灵活、高性能、高可用性的基础设施以及内置的安全性和简单的定价。此外，这种 OCI 实施还提供了卓越的可扩展性并减少了管理需求。
为什么 OCI Database for PostgreSQL 脱颖而出
-
性能提升高达 3 倍：得益于我们的数据库优化存储，将 SQL 事务处理引擎与存储层解耦，与标准 PostgreSQL 配置相比，性能显着增强。
-
成本不到友商的一半：当您在 OCI 上运行 PostgreSQL 时，您可以享受简单的定价以及较低的计算和存储费率，只需为您使用的资源付费，并且在所有区域（无论是在菲尼克斯、圣保罗还是东京）保持一致的定价。友商提供的同等服务比 OCI 上的价格贵 2.5 倍。
-
完全托管并为企业做好准备：从自动部署到安全更新，Oracle 会为您处理所有常见的维护任务 - 无论是适应不断增长的工作负载还是自动扩展存储。
-
值得信赖：与其他 OCI 数据存储和服务一样，OCI Database for PostgreSQL 提供始终在线的加密和定期安全更新，以增强数据保护并支持合规性。该服务与其他 OCI 安全服务（例如Audit、IAM和Cloud Guard）完全集成，以简化安全和治理管理。
-
高可用性：凭借 99.99% 的 SLA，并能够满足您的恢复时间目标 (RTO) 和恢复点目标 (RPO)，结合 OCI 架构创新和 PostgreSQL 数据库复制方法，我们为 OCI 上的 PostgreSQL 用户提供一流的耐用性和高可用性。
-
简单的用户体验：就像我们的其他产品一样，OCI Database for PostgreSQL 易于配置。数据库创建非常直观，设置后，您可以全面了解正在运行的数据库系统。详细的指标进一步有助于监控集群的健康状况。
PostgreSQL 是一种流行的数据库软件，它提供了原子性、一致性、隔离性和持久性，也称为ACID 属性。在Oracle 云基础设施(OCI)，Oracle对于如何打造出色的云数据库体验有着自己的看法。客户应该能够按需添加或删除数据库实例，独立地扩展计算和存储，并且服务的架构应该能够提供一流的性价比，而没有数据丢失的风险。这些是任何基于云的数据库服务的基本前提。以下是Oracle认为OCI PostgreSQL 服务需要包括的关键属性：
-
零恢复点目标（RPO）和零数据丢失：即使存在基础设施或系统故障，客户也不会丢失数据库中保存的任何数据。
-
一致的高性能：数据库性能不受后端系统任务（包括复制）的影响。
-
水平读取扩展：客户可以轻松地扩大和缩小读取容量，而不会影响写入性能。
-
性价比：客户的工作负载以更低的成本运行得更快。
-
完全自动化：客户通过软件修补、运行状况监控、数据库故障转移、备份和存储扩展等任务节省运营开销。
在下文中，我们将开源 PostgreSQL 称为“Vanilla PostgreSQL”。
尽管普通 Vanilla PostgreSQL 是功能强大且流行的数据库，但客户在使用它时仍面临以下一些挑战：
1.主要故障转移期间的数据丢失 - 非零 RPO：如图2所示，客户通常跨可用性域复制数据库实例。此复制是从 AD1 中的主数据库异步执行到 AD2 中的“副本”的。副本数据库可能落后于主数据库。如果主数据库发生故障并且副本被提升为新的主数据库，则可能会因滞后而丢失一些数据。数据丢失量取决于升级的副本与旧主副本的落后程度。vanilla PostgreSQL 中解决此问题的一个解决方案是同步复制功能，但由于性能开销巨大，因此不太受欢迎。
2.手动升级和可管理性的复杂性：尽管您可以在不同的可用性域中设置副本以实现高可用性，但将备用副本升级为主副本是一个手动且复杂的过程。必须谨慎选择要升级的新候选节点，从而有效减少数据丢失，同样，将旧主节点重新添加回集群需要更多手动步骤。例如，旧的主数据库可能有本地提交的多余事务，需要首先使用 pg_rewind 等工具清除这些事务，然后才能重新加入集群。
3.创建只读副本既昂贵又缓慢：使用普通 PostgreSQL，创建新副本需要在主数据库上拍摄数据快照并赶上主数据库。对于可能达到 TB 级的大型数据库，这是一项昂贵且缓慢的操作。为了能够处理应用程序的突发读取需求，客户必须过度配置数据库资源。由于每个副本必须具有数据库的完整副本，因此运行多个副本的存储成本可能会变得昂贵。
OCI Database with PostgreSQL – 高级架构
现在我们将探讨 OCI Database with PostgreSQL 的升级架构如何解决上述挑战，并使在 OCI 中运行和管理 PostgreSQL 变得非常简单。在OCI Database with PostgreSQL数据库中，Oracle将复制和持久性问题推到了新的数据库优化存储 (DbOS) 层，该层是专门为实现高规模、高可用性和高性能数据库服务而构建的。DbOS 提供高度耐用的网络附加存储，其中数据块在三个可用性域区域中的多个可用性域之间复制。在单 AD 区域中，数据跨多个故障域复制。集群中的所有 PostgreSQL 节点都访问相同的网络附加存储。每个备用副本不再需要维护自己的数据库副本。主实例写入共享存储，而备用副本实例从同一共享存储读取并服务用户查询。
OCI Database with PostgreSQL数据库中使用的这种新的共享存储架构在安全性、灵活性、效率和性能方面提供了许多优势。尽管 OCI Database with PostgreSQL 的底层存储架构完全不同，但它仍然与 vanilla PostgreSQL 完全兼容。因此，您可以将现有的 PostgreSQL 工作负载转移到带有 PostgreSQL 的 OCI 数据库，或者轻松地将它们移回原处。DbOS 是一个共享文件系统，利用内置复制等高性能 OCI 块存储功能。
数据库优化存储 (DbOS) 的优点
让我们详细说明为什么新嵌入的 DbOS 层对于 PostgreSQL 用户来说是一个如此强大的优势：
-
持久性（零 RPO）：DbOS 在多可用性域区域中跨多个可用性域复制数据，并且可以在整个可用性域丢失的情况下幸存下来。DbOS 使用基于仲裁的复制在幕后复制数据块。如果主节点发生故障，数据库可以故障转移到使用复制的 DbOS 的其他数据库节点，并且这个新升级的主 PostgreSQL 实例可以接管而不会丢失数据。之前在旧主数据库上提交的所有事务都存在于新主数据库中。由于 DbOS 层执行复制，因此无需仅仅为了持久性而运行多个副本实例。例如，可以在没有任何副本的情况下使用 PostgreSQL 实例运行单节点 OCI 数据库，但仍然不会牺牲耐用性。即使在这种单节点设置中，也保证您具有零 RPO。
-
高可用性 (99.99%)：使用OCI Database with PostgreSQL数据库，您可以在几分钟内自动将主数据库故障转移到集群中的另一个副本。主故障转移速度很快，并且对应用程序几乎是透明的，因为恢复时间目标只需要几分钟。为了透明地启用故障转移，主端点被设置为浮动IP地址，该地址会自动移动到新的主端点。故障转移后，应用程序会自动重新建立与新主数据库的数据库连接，无需对应用程序进行任何配置更改。与普通 PostgreSQL 不同，您在启动主故障转移时无需担心复制滞后和数据丢失。您无需手动选择特定副本来减少数据丢失。集群中的所有实例共享相同的存储，因此在故障转移时，新的主实例可以保证零数据丢失。
-
弹性：由于数据库存储在所有节点之间共享，因此您可以快速创建或删除副本，以满足用户查询工作负载需求。与普通 PostgreSQL 不同，您不需要在主节点上拍摄数据快照并将其复制到副本节点来启动新的备用 PostgreSQL 实例。因此，您可以像使用 PostgreSQL 在 OCI 数据库中启动计算实例一样快速地创建备用副本。
-
只读副本的水平扩展：由于副本节点与 PostgreSQL 共享 OCI 数据库中的数据库存储，因此无论数据库集群中的副本数量有多少，您只需要维护一份数据库副本。因此，与在云中运行普通 PostgreSQL 相比，带有 PostgreSQL 的 OCI 数据库可显着节省存储成本。此外，OCI 的 PostgreSQL 服务提供按使用量付费的数据定价模型，并具有自动扩展功能，可降低您的成本。
-
低副本延迟：复制延迟是普通 PostgreSQL 只读副本设置的一个主要挑战。由于副本必须重播并保存主副本所做的所有更改，因此很容易落后，尤其是在网络分区的情况下。通过共享存储，副本的工作量显着减少。它只需要将更改应用于其缓存中的页面，并且不必保留这些更改。使用这种架构，复制延迟通常以毫秒为单位，这使得读取查询能够近乎实时地执行或完成。
-
高效复制：OCI Database with PostgreSQL 在存储层执行复制。因此，主实例不需要将预写日志(WAL) 记录物理传送到所有副本。相反，它通知副本有新的更改，并且各个副本直接从共享存储读取latest WAL 记录。这可以减少主服务器上的负载，并且可以更有效地扩展到更多数量的副本。
在我们的实验中，具有内置跨AD复制功能的OCI Database with PostgreSQL数据库比普通 PostgreSQL 中的同步复制快两倍多。
进一步的存储优化
除了共享存储优化之外，OCI Database with PostgreSQL 还实施了以下优化以进一步提高性能。
-
原子写入：DbOS 针对已知的数据库性能风险实施优化，例如消除“撕裂写入”。通常，大多数数据库需要某种针对“撕裂写入”的保护，当数据库使用的页面大小（PostgreSQL 使用 8 KB）与底层存储的“原子写入单元”大小（通常为 512B 或4KB）。例如，如果这是自上一个检查点以来对页面的第一次修改，PostgreSQL 首先将整个 8KB 页面写入 WAL，然后将该页面刷新到磁盘。如果页面写入被破坏，那么 PostgreSQL 会回退到使用之前在 WAL 中写入的整页，并且不会造成任何损害。但这种保护是有代价的——它会导致 WAL 膨胀，并且频繁的检查点会加剧问题，而频繁的检查点需要减少计划外故障转移期间的恢复时间。我们在 DbOS 中实现了对 PostgreSQL 页面的原子写入支持。存储层永远不会覆盖现有页面。相反，它使用日志结构化技术始终将页面写入磁盘上的新位置，并维护从逻辑文件偏移到磁盘位置的映射层。旧版本的页面会定期被垃圾收集。这避免了双重写入。
-
优化的页面缓存：带有 PostgreSQL 的 OCI 数据库使用专门构建的缓存层，这与依赖于通用 Linux 内核页面缓存的普通 PostgreSQL 不同。OCI的页面缓存实现有很多优化，例如：
1.专为 PostgreSQL 工作负载定制的自定义预取逻辑。2.避免在 PostgreSQL 共享缓冲区和页面缓存中双重缓存页面3.通过预取数据页加速 PostgreSQL 恢复
-
存储级备份：在普通 Postgres 中，为了维护数据库备份，WAL 被复制到对象存储，并定期拍摄文件系统快照。此过程同时使用主节点上的网络和 CPU。OCI 数据库与 PostgreSQL 将备份委托给存储层，从而消除了备份的网络和 CPU 开销。
结论
正如前面详细介绍的，OCI Database with PostgreSQL数据库在成本、性能、规模、可用性和持久性方面提供了显着的优势。实现大部分优势的关键是基于 DbOS 和 DbFS，它们是专门为优化 PostgreSQL 以在云规模上更有效地工作而构建的。
要点
-
OCI 数据库与 PostgreSQL 使用专门构建的共享存储架构，其中所有数据库节点共享相同的底层 DbOS。
-
DbOS 自动跨区域复制数据，在主故障转移（零 RPO 故障转移）期间不会丢失数据。
-
OCI 数据库与 PostgreSQL 可以水平扩展读取工作负载，并在集群中的所有副本之间实现高性能一致的读取。
-
共享存储为客户节省了大量成本，因为他们不必存储多个数据副本，并且当数据大小减小时，存储会自动缩小。
编辑：殷海英
