AlloyDB Omni es un paquete de software de base de datos descargable que te permite implementar una versión optimizada de AlloyDB para PostgreSQL en tu propio entorno de procesamiento. AlloyDB Omni y el servicio completamente administrado de AlloyDB para PostgreSQL en Google Cloud comparten los mismos componentes principales. AlloyDB para PostgreSQL usa una capa de almacenamiento nativa de la nube que optimiza el rendimiento de WAL, mientras que AlloyDB Omni usa la misma interfaz de sistema de archivos estándar que usa PostgreSQL.
La portabilidad de AlloyDB Omni te permite ejecutarlo en muchos entornos, incluidos los siguientes:
- Centros de datos
- Laptops
- Instancias de VM basadas en la nube
Casos de uso de AlloyDB Omni
AlloyDB Omni es adecuado para las siguientes situaciones:
- Necesitas una versión escalable y de alto rendimiento de PostgreSQL, pero no puedes ejecutar una base de datos en la nube debido a requisitos regulatorios o de soberanía de los datos.
- Necesitas una base de datos que siga ejecutándose incluso cuando esté desconectada de Internet.
- Para minimizar la latencia, debes ubicar la base de datos lo más cerca posible de los usuarios.
- Te gustaría migrar de una base de datos heredada, pero sin comprometerte a una migración completa a la nube.
AlloyDB Omni no incluye las funciones de AlloyDB para PostgreSQL que dependen de la operación en Google Cloud. Si deseas actualizar tu proyecto a las funciones de escalamiento, seguridad y disponibilidad completamente administradas de AlloyDB para PostgreSQL, puedes migrar tus datos de AlloyDB Omni a un clúster de AlloyDB para PostgreSQL, al igual que lo puedes hacer con cualquier otra importación de datos inicial.
Características clave
- Un servidor de base de datos compatible con PostgreSQL
- Compatibilidad con AlloyDB AI, que te ayuda a compilar aplicaciones de IA generativa de nivel empresarial con tus datos operativos.
- Integraciones con el Google Cloud ecosistema de IA, incluido el Model Garden de Vertex AI y las herramientas de IA generativa de código abierto.
Compatibilidad con las funciones de piloto automático de AlloyDB para PostgreSQL enGoogle Cloud , que permite que AlloyDB Omni se autoadministre y autoajuste.
Por ejemplo, AlloyDB Omni admite la administración automática de la memoria y la autolimpieza automática adaptable de los datos inactivos.
Un asesor de índices que analiza las consultas que se ejecutan con frecuencia y recomienda índices nuevos para mejorar el rendimiento de las consultas.
El motor de columnas de AlloyDB Omni, que conserva los datos consultados con frecuencia en un formato de columnas en la memoria para obtener un rendimiento más rápido en inteligencia empresarial, informes y cargas de trabajo de procesamiento híbrido transaccional y analítico (HTAP).
En nuestras pruebas de rendimiento, las cargas de trabajo transaccionales en AlloyDB Omni son más del doble de rápidas, y las consultas analíticas son hasta 100 veces más rápidas, que PostgreSQL estándar.
Cómo funciona AlloyDB Omni
Puedes instalar AlloyDB Omni como un servidor independiente o como parte de un entorno de Kubernetes.
AlloyDB Omni se ejecuta en un contenedor de Docker que instalas en tu propio entorno. Te recomendamos que ejecutes AlloyDB Omni en un sistema Linux con almacenamiento SSD y al menos 8 GB de memoria por CPU.
El operador de Kubernetes de AlloyDB Omni es una extensión de la API de Kubernetes que te permite ejecutar AlloyDB Omni en la mayoría de los entornos de Kubernetes compatibles con CNCF. Para obtener más información, consulta Cómo instalar AlloyDB Omni en Kubernetes.
Tus aplicaciones se conectan y se comunican con tu instalación de AlloyDB Omni, al igual que las aplicaciones se conectan y se comunican con un estándar con un servidor de base de datos de PostgreSQL. El control de acceso de los usuarios también se basa en los estándares de PostgreSQL.
Desde el registro hasta la limpieza del motor de columnas, puedes configurar el comportamiento de la base de datos de AlloyDB Omni con marcas de base de datos.
Ventajas de ejecutar AlloyDB Omni como un contenedor
Google distribuye AlloyDB Omni como un contenedor que puedes ejecutar con entornos de ejecución de contenedores, como Docker y Podman. En términos operativos, los contenedores ofrecen las siguientes ventajas:
- Administración de dependencias transparente: Todas las dependencias necesarias se agrupan en el contenedor y Google las prueba para garantizar que sean totalmente compatibles con AlloyDB Omni.
- Portabilidad: Puedes esperar que AlloyDB Omni opere de manera coherente en todos los entornos.
- Aislamiento de seguridad: Tú eliges a qué tiene acceso el contenedor de AlloyDB Omni en la máquina host.
- Administración de recursos: Puedes definir la cantidad de recursos de procesamiento que quieres que use el contenedor de AlloyDB Omni.
- Aplicaciones de parches y actualizaciones sin inconvenientes: Para aplicar un parche a un contenedor, solo debes reemplazar la imagen existente por una nueva.
Copia de seguridad y recuperación ante desastres
AlloyDB Omni cuenta con un sistema de copia de seguridad y recuperación continuo que te permite crear un clúster de base de datos nuevo en función de cualquier momento dentro de un período de retención ajustable. Esto te permite recuperarte rápidamente de accidentes de pérdida de datos.
Además, AlloyDB Omni puede crear y almacenar copias de seguridad completas de los datos del clúster de tu base de datos, ya sea a pedido o de forma periódica. En cualquier momento, puedes restablecer desde una copia de seguridad a un clúster de bases de datos de AlloyDB Omni que contenga todos los datos del clúster de bases de datos original en el momento de la creación de la copia de seguridad.
Para obtener más información, consulta Cómo crear una copia de seguridad y restablecer AlloyDB Omni.
Como método adicional de recuperación ante desastres, puedes lograr la replicación entre centros de datos creando clústeres de bases de datos secundarios en centros de datos independientes. AlloyDB Omni transmite datos de forma asíncrona desde un clúster de base de datos principal designado a cada uno de sus clústeres secundarios. Cuando sea necesario, puedes ascender un clúster de base de datos secundario a un clúster de base de datos principal de AlloyDB Omni.
Para obtener más información, consulta Acerca de la replicación entre centros de datos.
Componentes de la VM de AlloyDB Omni
AlloyDB Omni en VM consta de dos conjuntos de componentes de arquitectura: componentes de PostgreSQL con mejoras de AlloyDB para PostgreSQL y componentes de AlloyDB para PostgreSQL. En el siguiente diagrama, se describen ambos conjuntos de componentes, en qué capa de infraestructura residen en una VM o un servidor, y las funciones relacionadas que puedes esperar para cada componente.
Figura 1. Arquitectura de AlloyDB Omni
Motor de base de datos
En este documento, se describe la arquitectura de la base de datos en AlloyDB Omni en un contenedor. En este documento, se supone que estás familiarizado con PostgreSQL.
Un motor de base de datos realiza las siguientes tareas:
- Traduce una consulta de un cliente en un plan ejecutable.
- Encuentra los datos necesarios para responder la consulta
- Realiza cualquier filtrado, ordenamiento y agregación necesarios
- Muestra los resultados al cliente

Cuando la aplicación cliente envía una consulta a AlloyDB Omni, se realizan las siguientes acciones:
- La capa de procesamiento de consultas convierte la consulta en un plan de ejecución que va a la capa de ejecución de consultas.
- La capa de ejecución de consultas realiza las operaciones necesarias para calcular la respuesta a la consulta.
- Durante la ejecución, los datos se pueden cargar desde la caché del búfer o directamente desde el almacenamiento. Si los datos se cargan desde el almacenamiento, estos se almacenan en la caché para usos futuros.
Los recursos que se usan cuando se procesa la consulta del cliente incluyen CPU, memoria, E/S, red y primitivas de sincronización, como bloqueos de bases de datos. El objetivo del ajuste de rendimiento es optimizar el uso de recursos durante cada uno de los pasos de la ejecución de consultas.
El objetivo de un motor de base de datos de alto rendimiento es responder a una consulta con los mínimos recursos necesarios. Este objetivo comienza con un buen modelo de datos y un diseño de consulta.
- ¿Cómo se pueden responder las consultas mientras se observa la menor cantidad de datos?
- ¿Qué índices se necesitan para reducir el espacio de búsqueda y las operaciones de E/S?
- La clasificación de datos requiere CPU y, a menudo, acceso al disco para conjuntos de datos grandes, por lo que, ¿cómo se puede evitar la clasificación de datos?
Almacenamiento de datos
AlloyDB Omni almacena datos en páginas de tamaño fijo que se almacenan en el sistema de archivos subyacente. Cuando una consulta necesita acceder a los datos, AlloyDB Omni primero verifica el grupo de búferes. Si no se encuentran las páginas que contienen los datos requeridos en el grupo de búferes, AlloyDB Omni lee las páginas requeridas del sistema de archivos. El acceso a los datos desde el grupo de búferes es mucho más rápido que la lectura desde el sistema de archivos y, por lo tanto, maximizar el tamaño del grupo de búferes para la cantidad de datos a los que accederá una aplicación es un factor importante.
Administración de recursos
AlloyDB Omni usa la administración de memoria dinámica para permitir que el grupo de búferes crezca y se reduzca de forma dinámica dentro de los límites configurados según las demandas de memoria del sistema. Por lo tanto, no es necesario ajustar el tamaño del grupo de búferes. Cuando diagnostiques problemas de rendimiento, las primeras métricas que debes tener en cuenta son la tasa de aciertos del grupo de búferes y la tasa de lectura para ver si tu aplicación obtiene el beneficio del grupo de búferes. De lo contrario, significa que el conjunto de datos de la aplicación no se ajusta al grupo de búferes y que podrías considerar cambiar el tamaño a una máquina más grande con más memoria.
El proceso de recuperar, filtrar, agregar, ordenar y proyectar datos requiere recursos de CPU en el servidor de la base de datos. Para reducir la cantidad de recursos de CPU necesarios para este proceso, minimiza la cantidad de datos que se deben manipular. Supervisa el uso de CPU en el servidor de la base de datos para asegurarte de que el uso en estado estable sea de alrededor del 70%. Esta cantidad deja un margen suficiente en el servidor para aumentos repentinos en el uso o cambios en los patrones de acceso con el tiempo. Ejecutar el sistema con un uso cercano al 100% genera una sobrecarga debido a la programación de procesos y el cambio de contexto, y puede crear cuellos de botella en otras partes del sistema. El alto uso de CPU es otra métrica clave que se debe usar cuando se toman decisiones sobre las especificaciones de la máquina.
Las operaciones de entrada y salida por segundo (IOPS) son un factor importante en el rendimiento de las aplicaciones de bases de datos: cuántas operaciones de entrada o salida por segundo puede entregar el dispositivo de almacenamiento subyacente a la base de datos. Para evitar alcanzar los límites de IOPS del almacenamiento de bases de datos, minimiza las operaciones de lectura y escritura en el almacenamiento maximizando la cantidad de datos que pueden caber en el grupo de almacenamiento en búfer.
Motor de columnas
El motor de columnas acelera el procesamiento de consultas en SQL de análisis, uniones y agrupaciones proporcionando los siguientes componentes:
Almacén de columnas en memoria: Contiene datos de tablas y vistas materializadas para columnas seleccionadas en un formato orientado a columnas. De forma predeterminada, el almacén de columnas consume 1 GB de memoria disponible. Para cambiar la cantidad de memoria que puede usar el almacén de columnas, establece el parámetro
google_columnar_engine.memory_size_in_mb
en elpostgresql.conf
que usa tu instancia de AlloyDB Omni.Para obtener más información sobre cómo cambiar el parámetro, consulta Cómo cambiar los parámetros de configuración.
Planificador de consultas y motor de ejecución de columnas: Admite el uso del almacén de columnas en las consultas.
Administración automática de la memoria
El administrador de memoria automático supervisa y optimiza de forma continua el consumo de memoria en una instancia completa de AlloyDB Omni. Cuando ejecutas
tus cargas de trabajo, este módulo ajusta el tamaño de la caché del búfer compartido según la presión
de la memoria. De forma predeterminada, el administrador de memoria automático establece el límite superior en el 80% de la memoria del sistema y asigna el 10% de la memoria del sistema para la caché de búfer compartida.
Para cambiar el límite superior del tamaño de la caché del búfer compartido, establece el parámetro shared_buffers
en el postgresql.conf
que usa tu instancia de AlloyDB Omni.
Para obtener más información, consulta Administración automática de la memoria.
Limpieza automática adaptable
La aspiración automática adaptable analiza las operaciones en función de la carga de trabajo de la base de datos y ajusta automáticamente la frecuencia de la aspiración. Este ajuste automático ayuda a que la base de datos se ejecute con el máximo rendimiento, incluso a medida que cambia la carga de trabajo, sin interferencias del proceso de limpieza.
La limpieza automática adaptativa usa los siguientes factores para determinar la frecuencia y intensidad de las operaciones de limpieza:
- Tamaño de la base de datos
- Cantidad de tuplas muertas en la base de datos
- La antigüedad de los datos en la base de datos
- Cantidad de transacciones por segundo en comparación con la velocidad de limpieza estimada
La limpieza automática adaptativa proporciona los siguientes beneficios:
- Administración dinámica de recursos de limpieza: En lugar de usar un límite de costo fijo, AlloyDB Omni usa estadísticas de recursos en tiempo real para ajustar los trabajadores de limpieza. Cuando el sistema está ocupado, se regulan el proceso de limpieza y el uso de recursos asociado. Si hay suficiente memoria disponible, se asigna memoria adicional para
maintenance_work_mem
para reducir el tiempo de limpieza de extremo a extremo. - Restricción dinámica de XID: Supervisa automáticamente y de forma continua el progreso de la limpieza y la velocidad del consumo de IDs de transacción. Si se detecta un riesgo de ajuste de ID de transacción, AlloyDB Omni ralentiza las transacciones para reducir el consumo de ID. Además,
AlloyDB Omni asigna más recursos a los trabajadores de limpieza
para procesar las tablas que bloquean el avance y la liberación del espacio de ID de transacción. Durante este proceso, las transacciones generales por segundo se reducen hasta que los IDs de transacción se encuentran en una zona segura (observable como sesiones que esperan en
AdaptiveVacuumNewXidDelay
). Cuando aumenta la antigüedad del ID de transacción, los trabajadores de limpieza aumentan de forma dinámica. - Limpieza eficiente para tablas más grandes: La lógica predeterminada de PostgreSQL que se usa para decidir cuándo limpiar una tabla se basa en estadísticas específicas de la tabla almacenadas en
pg_stat_all_tables
, que contiene la proporción de tuplas inactivas. Esta lógica funciona para tablas pequeñas, pero es posible que no funcione de manera eficiente para tablas más grandes que se actualizan con frecuencia. AlloyDB Omni proporciona un mecanismo de análisis actualizado que ayuda a activar la limpieza automática con más frecuencia. Este mecanismo de análisis analiza fragmentos de tablas grandes y quita las tuplas inactivas de manera más eficiente que la lógica predeterminada de PostgreSQL. - Registra mensajes de advertencia: En AlloyDB Omni, se detectan los bloqueadores de vacío, como las transacciones de larga duración, las transacciones preparadas o los espacios de replicación que perdieron sus objetivos, y se registran advertencias en los registros de PostgreSQL para que puedas abordar los problemas de forma oportuna.
Trabajador de IA/AA
En AlloyDB Omni, el trabajador en segundo plano de IA/AA proporciona todas las funciones necesarias para llamar a modelos de Vertex AI directamente desde la base de datos. El trabajador de IA/AA se ejecuta como un proceso llamado omni ml worker
.
Para obtener más información, consulta Cómo compilar aplicaciones de IA generativa con AlloyDB AI.