AlloyDB Omni 概览

AlloyDB Omni 是一个可下载的数据库软件包，可让您在自己的计算环境中部署简化版本的 AlloyDB for PostgreSQL。AlloyDB Omni 和 Google Cloud 上的全托管式 AlloyDB for PostgreSQL 服务共享相同的核心组件。AlloyDB for PostgreSQL 使用可优化 WAL 性能的云原生存储层，而 AlloyDB Omni 使用 PostgreSQL 所用的标准文件系统接口。

AlloyDB Omni 的可移植性使您可以在许多环境中运行它，包括：

  • 数据中心
  • 笔记本电脑
  • 云端虚拟机实例

AlloyDB Omni 应用场景

AlloyDB Omni 非常适合以下场景：

  • 您需要一个可伸缩且高性能的 PostgreSQL 版本，但由于监管或数据主权要求，您无法在云端运行数据库。
  • 您需要一个即使与互联网断开连接也能继续运行的数据库。
  • 为了尽可能缩短延迟时间，您需要将数据库放置在尽可能靠近用户的地理位置处。
  • 您希望能够从旧版数据库迁出，但不想进行全面的云迁移。

AlloyDB Omni 不包含依赖于 Google Cloud中的操作的 AlloyDB for PostgreSQL 功能。如果您想将项目升级到 AlloyDB for PostgreSQL 的全托管式扩缩、安全和可用性功能，可以将 AlloyDB Omni 数据迁移到 AlloyDB for PostgreSQL 集群，就像使用任何其他初始数据导入一样。

主要特性

  • 与 PostgreSQL 兼容的数据库服务器。
  • 对 AlloyDB AI 的支持，可帮助您使用运营数据构建企业级生成式 AI 应用。
  • 与 Google Cloud AI 生态系统的集成，包括 Vertex AI Model Garden 和开源生成式 AI 工具。

  • 对Google Cloud 中 AlloyDB for PostgreSQL 的 Autopilot 功能的支持，让 AlloyDB Omni 能够自行管理和自行调优。

    例如，AlloyDB Omni 支持自动内存管理和过时数据的自适应自动完全清理 (autovacuum)。

  • 索引顾问，可分析经常运行的查询并推荐新索引，以提高查询性能。

  • AlloyDB Omni 列式引擎，该引擎能够以内存中列式格式保存频繁查询的数据，从而加快商业智能、报告以及混合事务和分析处理 (HTAP) 工作负载的速度。

在我们的性能测试中，与标准 PostgreSQL 相比，AlloyDB Omni 处理事务型工作负载的速度高达 2 倍以上，处理分析型查询的速度高达 100 倍以上。

AlloyDB Omni 的工作原理

您可以将 AlloyDB Omni 作为独立服务器或作为 Kubernetes 环境的一部分进行安装。

AlloyDB Omni 在安装到您自己的环境的 Docker 容器中运行。我们建议您在配备 SSD 存储空间且每个 CPU 至少有 8GB 内存的 Linux 系统上运行 AlloyDB Omni。

AlloyDB Omni Kubernetes 操作器是 Kubernetes API 的扩展程序，可让您在大多数符合 CNCF 标准的 Kubernetes 环境中运行 AlloyDB Omni。如需了解详情，请参阅在 Kubernetes 上安装 AlloyDB Omni。

您的应用会连接到 AlloyDB Omni 安装并与之通信，就像应用连接到标准 PostgreSQL 数据库服务器并与之通信一样。用户访问权限控制也依赖于 PostgreSQL 标准。

从日志记录到完全清理 (vacuum) 再到列式引擎，您可以使用数据库标志配置 AlloyDB Omni 的数据库行为。

以容器形式运行 AlloyDB Omni 的优势

Google 以容器形式分发 AlloyDB Omni，您可以使用 Docker 和 Podman 等容器运行时运行该容器。在操作方面，容器具有以下优势：

  • 透明的依赖项管理：所有必要的依赖项都已捆绑到容器中，并已由 Google 进行测试，以确保它们与 AlloyDB Omni 完全兼容。
  • 可移植性：您可以期望 AlloyDB Omni 在各个环境中都能一致运行。
  • 安全隔离：您可以选择 AlloyDB Omni 容器在宿主机上有权访问的内容。
  • 资源管理：您可以定义希望 AlloyDB Omni 容器使用的计算资源数量。
  • 无缝修补和升级：如需修补容器，您只需用新映像替换现有映像。

数据备份和灾难恢复

AlloyDB Omni 具有持续备份和恢复系统，可让您根据可调整的保留期限内的任意时间点创建新的数据库集群。这使您可以在发生数据丢失事故时快速恢复。

此外，AlloyDB Omni 还可以按需或定期创建和存储数据库集群数据的完整备份。您可以随时从备份恢复到一个 AlloyDB Omni 数据库集群，该集群包含创建备份时原始数据库集群中的所有数据。

如需了解详情，请参阅备份和恢复 AlloyDB Omni。

作为灾难恢复的进一步方法，您可以在不同的数据中心创建次要数据库集群，以实现跨数据中心复制。AlloyDB Omni 会异步地将数据从指定的主数据库集群流式传输到每个次要集群。在需要时，您可以将次要数据库集群提升为主 AlloyDB Omni 数据库集群。

如需了解详情，请参阅跨数据中心复制简介

AlloyDB Omni 虚拟机组件

虚拟机上的 AlloyDB Omni 包含两组架构组件：具有 AlloyDB for PostgreSQL 增强功能的 PostgreSQL 组件以及 AlloyDB for PostgreSQL 组件。下图概述了这两组组件、它们在虚拟机或服务器上所属的基础设施层以及每个组件的相关预期功能。

AlloyDB Omni 组件架构图，其中将 AlloyDB for PostgreSQL 特有的组件与 PostgreSQL 组件分开。

图 1. AlloyDB Omni 架构

数据库引擎

本文档介绍了容器中 AlloyDB Omni 的数据库架构。本文档假定您熟悉 PostgreSQL。

数据库引擎会执行以下任务：

  1. 将来自客户端的查询转换为可执行的计划
  2. 查找满足查询所需的数据
  3. 执行任何必要的过滤、排序和汇总
  4. 将结果返回给客户端
显示客户端应用如何与数据库层交互的示意图。
图 1. 显示协同工作以响应来自客户端应用的查询的数据库层。

当客户端应用向 AlloyDB Omni 发送查询时，系统会执行以下操作：

  1. 查询处理层将查询转换为执行计划，然后前往查询执行层。
  2. 查询执行层执行计算查询响应所需的操作。
  3. 在执行期间，数据可以从缓冲区缓存加载，也可以直接从存储空间加载。如果数据是从存储空间加载的，则存储空间中的数据会存储在缓存中以供将来使用。

处理客户端查询时使用的资源包括 CPU、内存、I/O、网络和同步原语（如数据库锁）。性能调优旨在优化查询执行过程中的每个步骤的资源利用率。

高性能数据库引擎的目标是使用所需的最少资源响应查询。如需实现此目标，首先要有一个良好的数据模型和查询设计。

  • 如何在查看最少量数据的同时回答查询？
  • 需要什么样的索引才能缩减搜索空间和 I/O？
  • 对数据进行排序需要 CPU，并且对于大型数据集通常需要访问磁盘，那么如何避免对数据进行排序呢？

数据存储

AlloyDB Omni 会将数据存储在固定大小的页面中，而这些页面存储在底层文件系统中。当查询需要访问数据时，AlloyDB Omni 会先检查缓冲区池。如果未在缓冲区池中找到包含所需数据的页面，AlloyDB Omni 会从文件系统中读取所需页面。从缓冲区池访问数据比从文件系统读取数据要快得多，因此，针对应用会访问的数据量最大限度地增加缓冲区池的大小是一个重要因素。

资源管理

AlloyDB Omni 使用动态内存管理，可让缓冲区池在配置的边界内根据系统的内存需求动态扩大和缩小。因此，无需调整缓冲区池大小。诊断性能问题时，首先要考虑的指标是缓冲区池命中率和读取速率，以了解应用是否从缓冲区池中获益。如果应用未从中获益，则表示应用的数据集不适合缓冲区池，您可以考虑调整大小以使用具有更多内存的更大机器。

对数据进行检索、过滤、汇总、排序和投影的过程都需要数据库服务器上的 CPU 资源。如需减少此过程所需的 CPU 资源量，请尽量减少需要操作的数据量。监控数据库服务器上的 CPU 利用率，确保稳定状态利用率约为 70%。此数量可在服务器上留出足够的余量，以应对利用率激增或访问模式随时间的变化。以接近 100% 的利用率运行会因进程调度和上下文切换而引入开销，并可能会在系统的其他部分造成瓶颈。在决定机器规格时，高 CPU 利用率是另一个关键指标。

每秒输入/输出操作数 (IOPS) 是数据库应用性能的一个重要因素，即底层存储设备每秒可以向数据库传送的输入或输出操作数。为避免达到数据库存储空间的 IOPS 限制，请通过最大限度地增加缓冲区池中可容纳的数据量来最大限度地减少对存储空间的读写操作。

列式引擎

列式引擎通过提供以下组件来加快扫描、联接和汇总的 SQL 查询处理速度。

  • 内存中列存储区：包含所选列的表和物化视图数据（以面向列的格式存储）。默认情况下，列存储区会占用 1GB 的可用内存。如需更改列存储区可使用的内存量，请在 AlloyDB Omni 实例使用的 postgresql.conf 中设置 google_columnar_engine.memory_size_in_mb 参数。

    如需详细了解如何更改该参数，请参阅更改配置参数。

  • 列式查询规划工具和执行引擎：支持在查询中使用列存储区。

自动内存管理

自动内存管理器会持续监控并优化整个 AlloyDB Omni 实例中的内存消耗。当您运行工作负载时，此模块会根据内存压力调整共享缓冲区缓存大小。默认情况下，自动内存管理器会将上限设置为系统内存的 80%，并为共享缓冲区缓存分配 10% 的系统内存。如需更改共享缓冲区缓存大小的上限，请在 AlloyDB Omni 实例使用的 postgresql.conf 中设置 shared_buffers 参数。

如需了解详情，请参阅自动内存管理。

自适应自动完全清理 (autovacuum)

自适应自动完全清理 (autovacuum) 会根据数据库的工作负载分析操作，并自动调整完全清理 (vacuum) 的频率。这种自动调整有助于数据库即使在工作负载发生变化时也能以最佳性能运行，而不会受到完全清理 (vacuum) 进程的干扰。

自适应自动完全清理 (autovacuum) 使用以下因素来确定完全清理 (vacuum) 操作的频率和强度：

  • 数据库大小
  • 数据库中的不活跃元组数量
  • 数据库中数据的存在时间
  • 每秒事务数量与估算的完全清理 (vacuum) 速度

自适应自动完全清理 (autovacuum) 具有以下优势：

  • 动态完全清理 (vacuum) 资源管理：AlloyDB Omni 使用实时资源统计信息来调整完全清理 (vacuum) 工作器，而不是使用固定费用限制。当系统繁忙时，完全清理 (vacuum) 进程和关联资源利用率会受到限制。如果有足够的内存可用，系统会为 maintenance_work_mem 分配额外的内存，以缩短端到端完全清理 (vacuum) 时间。
  • 动态 XID 限制：自动且持续地监控完全清理 (vacuum) 进度和事务 ID 消耗速度。如果检测到事务 ID 回卷风险，AlloyDB Omni 会减慢事务处理速度，以限制 ID 消耗。此外，AlloyDB Omni 会向完全清理 (vacuum) 工作器分配更多资源，以处理阻止事务 ID 空间推进和释放的表。在此过程中，每秒事务总数会减少，直到事务 ID 进入安全区（可观察到等待 AdaptiveVacuumNewXidDelay 的会话）。随着事务 ID 存在时间的增加，完全清理 (vacuum) 工作器会动态增加。
  • 较大表的高效完全清理 (vacuum)：用于确定何时完全清理 (vacuum) 表的默认 PostgreSQL 逻辑基于存储在 pg_stat_all_tables 中的表特有的统计信息（其中包含不活跃元组比率）。此逻辑适用于小型表，但对于频繁更新的较大表，可能无法高效运行。AlloyDB Omni 提供了一个经过更新的扫描机制，可帮助更频繁地触发自动完全清理 (autovacuum)。与默认的 PostgreSQL 逻辑相比，此扫描机制可以更高效地扫描大型表的数据块并移除不活跃的元组。
  • 记录警告消息：在 AlloyDB Omni 中，系统会检测完全清理 (vacuum) 阻碍因素（例如长时间运行的事务或是丢失目标的已准备好事务或复制槽），并在 PostgreSQL 日志中记录警告，以便您及时解决问题。

AI/机器学习工作器

在 AlloyDB Omni 中，AI/机器学习后台工作器提供直接从数据库调用 Vertex AI 模型所需的所有功能。AI/机器学习工作器以名为 omni ml worker 的进程形式运行。

如需了解详情，请参阅使用 AlloyDB AI 构建生成式 AI 应用。