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 reglamentarios o de soberanía de datos.
- Necesitas una base de datos que siga funcionando incluso cuando está desconectada de Internet.
- Para minimizar la latencia, deseas ubicar tu base de datos lo más cerca posible de tus usuarios.
- Te gustaría una forma de migrar desde una base de datos heredada, pero sin comprometerte con una migración completa a la nube.
AlloyDB Omni no incluye funciones de AlloyDB que dependan de la operación en Google Cloud. Si deseas actualizar tu proyecto a las funciones de escalamiento, seguridad y disponibilidad completamente administradas de AlloyDB, puedes migrar tus datos de AlloyDB Omni a un clúster de AlloyDB, al igual que 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 Vertex AI Model Garden y herramientas de IA generativa de código abierto
Compatibilidad con las funciones de piloto automático de AlloyDB en Google Cloud que permite que AlloyDB Omni se administre y ajuste automáticamente.
Por ejemplo, AlloyDB Omni admite la administración automática de la memoria y la aspiración automática adaptable de datos obsoletos.
Un asesor de índice 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 tú 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 comunican con tu instalación de AlloyDB Omni, al igual que las aplicaciones se conectan y comunican con un estándar con un servidor de base de datos de PostgreSQL. El control de acceso del usuario también se basa en los estándares de PostgreSQL.
Desde el registro hasta la aspiración y el motor de columnas, puedes configurar el comportamiento de la base de datos de AlloyDB Omni con indicadores 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 presentan las siguientes ventajas:
- Administración transparente de dependencias: Todas las dependencias necesarias se agrupan en el contenedor y Google las prueba para garantizar que sean completamente compatibles con AlloyDB Omni.
- Portabilidad: Puedes esperar que AlloyDB Omni funcione de manera coherente en todos los entornos.
- Aislamiento de seguridad: Elige a qué tiene acceso el contenedor de AlloyDB Omni en la máquina anfitrión.
- Administración de recursos: Puedes definir la cantidad de recursos de procesamiento que deseas que use el contenedor de AlloyDB Omni.
- Actualizaciones y aplicación de parches sin problemas: Para aplicar un parche a un contenedor, solo debes reemplazar la imagen existente por una nueva.
Copia de seguridad y recuperación ante desastres de datos
AlloyDB Omni incluye un sistema continuo de copia de seguridad y recuperación que te permite crear un clúster de base de datos nuevo basado en 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 de tu clúster de 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 base de datos de AlloyDB Omni que contenga todos los datos del clúster de base 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 base 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 promover 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 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 a un plan ejecutable.
- Encuentra los datos necesarios para satisfacer la consulta.
- Realiza cualquier filtrado, orden y agregación necesarios.
- Muestra los resultados al cliente.
Cuando la aplicación cliente envía una consulta a AlloyDB Omni, se producen 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, 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 base de datos. El ajuste de rendimiento tiene como objetivo 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 la menor cantidad de recursos necesarios. Este objetivo comienza con un buen modelo de datos y diseño de consultas.
- ¿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 la E/S?
- Ordenar datos requiere CPU y, a menudo, acceso al disco para conjuntos de datos grandes, por lo que ¿cómo se puede evitar la ordenació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 significativamente 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 dinámica de la memoria 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 considerar son la tasa de aciertos del grupo de búferes y la tasa de lectura para ver si tu aplicación se beneficia del grupo de búferes. Si no es así, indica que el conjunto de datos de la aplicación no cabe en el grupo de búferes y podrías considerar cambiar el tamaño a una máquina más grande con más memoria.
El proceso de recuperación, filtrado, agregación, ordenación y proyección de datos requiere recursos de CPU en el servidor de 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 base de datos para asegurarte de que el uso en estado estable sea de alrededor del 70%. Esta cantidad deja suficiente espacio libre en el servidor para los aumentos repentinos en el uso o los cambios en los patrones de acceso a lo largo del tiempo. Ejecutar con un uso más cercano al 100% introduce 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 uso alto 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 la aplicación de base 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 la base de datos, minimiza las lecturas y escrituras en el almacenamiento maximizando la cantidad de datos que pueden caber en el grupo de búferes.
Motor de columnas
El motor de columnas acelera el procesamiento de consulta en SQL de análisis, uniones y agregaciones proporcionando los siguientes componentes:
Almacén de columnas en la memoria: Contiene datos de tablas y vistas materializadas para las 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_mben elpostgresql.confque usa tu instancia de AlloyDB Omni.Para obtener más información sobre cómo cambiar el parámetro, consulta Cambia los parámetros de configuración.
Motor de ejecución y planificación de consultas en columnas: Admite el uso del almacén de columnas en las consultas.
Administración automática de la memoria
El administrador automático de la memoria supervisa y optimiza continuamente el consumo de memoria en toda una instancia de AlloyDB Omni. Cuando ejecutas tus cargas de trabajo, este módulo ajusta el tamaño de la caché del búfer compartido en función de la presión de la memoria. De forma predeterminada, el administrador automático de la memoria establece el límite superior en el 80% de la memoria del sistema y asigna el 10% de la memoria del sistema a la caché del búfer compartido.
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.
Aspiración 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 cuando cambia la carga de trabajo, sin interferencias del proceso de aspiración.
La aspiración automática adaptable usa los siguientes factores para determinar la frecuencia y la intensidad de las operaciones de aspiración:
- Tamaño de la base de datos
- Cantidad de tuplas inactivas en la base de datos
- Antigüedad de los datos en la base de datos
- Cantidad de transacciones por segundo en comparación con la velocidad de aspiración estimada
La aspiración automática adaptable proporciona los siguientes beneficios:
- Administración dinámica de recursos de aspiración: 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 aspiración. Cuando el sistema está ocupado, se limita el proceso de aspiración y el uso de recursos asociado. Si hay suficiente memoria disponible, se asigna memoria adicional para
maintenance_work_mempara reducir el tiempo de aspiración de extremo a extremo. - Limitación dinámica de XID: Supervisa de forma automática y continua el
progreso de la aspiración y la velocidad del consumo de ID de transacción. Si se detecta un riesgo de ajuste de ID de transacción, AlloyDB Omni ralentiza las transacciones para limitar el consumo de ID. Además, AlloyDB Omni asigna más recursos a los trabajadores de aspiración para procesar las tablas que bloquean el avance y la liberación del espacio de ID de transacción. Durante este proceso, se reducen las transacciones generales por segundo 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 aspiración aumentan de forma dinámica. - Aspiración eficiente para tablas más grandes: La lógica predeterminada de PostgreSQL
que se usa para decidir cuándo aspirar 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 aspiración 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. - Mensajes de advertencia de registro: En AlloyDB Omni, se detectan los bloqueadores de aspiración, como las transacciones de larga duración o las transacciones preparadas o los espacios de replicación que perdieron sus destinos, y se registran advertencias en los registros de PostgreSQL para que puedas abordar los problemas de manera oportuna.
Trabajador de IA/AA
En AlloyDB Omni, el trabajador en segundo plano de IA/AA proporciona todas las capacidades necesarias para llamar a los 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 Compila aplicaciones de IA generativa con AlloyDB AI.
¿Qué sigue?
- Obtén información sobre las opciones de descarga e instalación de AlloyDB Omni.
- Realiza una guía de inicio rápido para instalar AlloyDB Omni en una VM.
- Realiza una instalación de instancia única de AlloyDB Omni en cualquier VM de Linux.
- Aprende a instalar AlloyDB Omni en Kubernetes.