La portabilidad de AlloyDB Omni te permite ejecutarlo en muchos entornos, incluidos los siguientes:
- Centros de datos
- Portátiles
- Instancias de VM basadas en la nube
Casos prácticos de AlloyDB Omni
AlloyDB Omni es una solución adecuada para los siguientes casos:
- Necesitas una versión de PostgreSQL escalable y con buen rendimiento, pero no puedes ejecutar una base de datos en la nube debido a requisitos normativos o de soberanía de los datos.
- Necesitas una base de datos que siga funcionando aunque no esté conectada a Internet.
- Para minimizar la latencia, debe ubicar su base de datos lo más cerca posible de sus usuarios.
- Quieres migrar de una base de datos antigua, pero sin comprometerte a realizar una migración completa a la nube.
AlloyDB Omni no incluye funciones de AlloyDB para PostgreSQL que dependan de operaciones en Google Cloud. Si quieres actualizar tu proyecto a las funciones de escalado, seguridad y disponibilidad totalmente gestionadas de AlloyDB para PostgreSQL, puedes migrar tus datos de AlloyDB Omni a un clúster de AlloyDB para PostgreSQL del mismo modo que lo harías con cualquier otra importación de datos inicial.
Características principales
- Un servidor de bases de datos compatible con PostgreSQL.
- Compatibilidad con AlloyDB AI, que te ayuda a crear aplicaciones de IA generativa de nivel empresarial con tus datos operativos.
- Integraciones con el ecosistema de IA, incluido Vertex AI Model Garden y herramientas de IA generativa de código abierto. Google Cloud
Compatibilidad con las funciones de piloto automático de AlloyDB para PostgreSQL, que permite que AlloyDB Omni se gestione y se ajuste automáticamente.Google Cloud
Por ejemplo, AlloyDB Omni admite la gestión automática de la memoria y el autovacuum adaptativo de los datos obsoletos.
Un asesor de indexación que analiza las consultas que se ejecutan con frecuencia y recomienda nuevos índices para mejorar el rendimiento de las consultas.
El motor en columnas de AlloyDB Omni, que mantiene los datos consultados con frecuencia en un formato de columna en memoria para agilizar el rendimiento de la inteligencia empresarial, los informes y el procesamiento transaccional y analítico híbrido (HTAP).
En nuestras pruebas de rendimiento, las cargas de trabajo transaccionales de AlloyDB Omni son más del doble de rápidas y las consultas analíticas son hasta 100 veces más rápidas que las del estándar PostgreSQL.
Cómo funciona AlloyDB Omni
Puedes instalar AlloyDB Omni como servidor independiente o como parte de un entorno de Kubernetes.
AlloyDB Omni se ejecuta en un contenedor 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 AlloyDB Omni Kubernetes es una extensión de la API de Kubernetes que te permite ejecutar AlloyDB Omni en la mayoría de los entornos de Kubernetes que cumplan con la norma CNCF. Para obtener más información, consulta 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 servidor de base de datos PostgreSQL estándar. El control de acceso de los usuarios también se basa en los estándares de PostgreSQL.
Desde el registro hasta el vacío y el motor de columnas, puedes configurar el comportamiento de la base de datos de AlloyDB Omni mediante marcas de bases de datos.
Ventajas de ejecutar AlloyDB Omni como contenedor
Google distribuye AlloyDB Omni como un contenedor que puedes ejecutar con entornos de ejecución de contenedores como Docker y Podman. Desde el punto de vista operativo, los contenedores ofrecen las siguientes ventajas:
- Gestión de dependencias transparente: todas las dependencias necesarias se incluyen en el contenedor y Google las prueba para asegurarse de que sean totalmente compatibles con AlloyDB Omni.
- Portabilidad: AlloyDB Omni funciona de forma coherente en todos los entornos.
- Aislamiento de seguridad: tú eliges a qué puede acceder el contenedor de AlloyDB Omni en la máquina host.
- Gestión de recursos: puedes definir la cantidad de recursos de computación que quieres que use el contenedor de AlloyDB Omni.
- Parches y actualizaciones sin interrupciones: para aplicar un parche a un contenedor, solo tienes que sustituir la imagen actual por una nueva.
Copias de seguridad de datos y recuperación en caso de desastre.
AlloyDB Omni incluye un sistema de copias de seguridad y recuperación continuas que te permite crear un nuevo clúster de base de datos basado en cualquier momento dado dentro de un periodo de conservación ajustable. De esta forma, puedes recuperarte rápidamente de los 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 bajo demanda o de forma periódica. En cualquier momento, puedes restaurar una copia de seguridad en 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 Crear copias de seguridad y restaurar AlloyDB Omni.
Como método adicional de recuperación tras desastres, puedes conseguir 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 convertir un clúster de base de datos secundaria en un clúster de base de datos principal de AlloyDB Omni.
Para obtener más información, consulta el artículo Acerca de la replicación entre centros de datos.
Componentes de la VM de AlloyDB Omni
AlloyDB Omni en una 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, la capa de infraestructura en la que se encuentran en una máquina virtual o un servidor, y las funciones relacionadas que puede esperar de cada componente.
Imagen 1. Arquitectura de AlloyDB Omni
Motor de base de datos
En este documento se describe la arquitectura de la base de datos de AlloyDB Omni en un contenedor. En este documento se da por hecho que conoces PostgreSQL.
Un motor de base de datos realiza las siguientes tareas:
- Traduce una consulta de un cliente en un plan ejecutable.
- Busca los datos necesarios para responder a la consulta.
- Realiza el filtrado, la ordenación y la agregación necesarios.
- Devuelve 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 se envía 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é de búfer o directamente desde el almacenamiento. Si los datos se cargan desde el almacenamiento, se almacenan en la caché para usarlos en el futuro.
Los recursos que se usan al procesar la consulta del cliente incluyen la CPU, la memoria, las operaciones de entrada/salida, la red y las primitivas de sincronización, como los bloqueos de bases de datos. El ajuste del rendimiento tiene como objetivo optimizar el uso de los recursos durante cada uno de los pasos de la ejecución de la consulta.
El objetivo de un motor de base de datos eficiente es responder a una consulta con los mínimos recursos necesarios. Este objetivo empieza con un buen modelo de datos y un diseño de consulta.
- ¿Cómo se pueden responder las consultas con la menor cantidad de datos posible?
- ¿Qué índices se necesitan para reducir el espacio de búsqueda y las operaciones de entrada/salida?
- Para ordenar datos, se necesita CPU y, a menudo, acceso al disco en el caso de conjuntos de datos grandes. Por lo tanto, ¿cómo se puede evitar ordenar datos?
Almacenamiento de datos
AlloyDB Omni almacena los 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 comprueba el grupo de búferes. Si las páginas que contienen los datos necesarios no se encuentran en el grupo de búferes, AlloyDB Omni lee las páginas necesarias del sistema de archivos. Acceder a los datos del grupo de búferes es mucho más rápido que leerlos del sistema de archivos, por lo que es importante maximizar el tamaño del grupo de búferes en función de la cantidad de datos a los que accederá una aplicación.
Gestión de recursos
AlloyDB Omni usa la gestión dinámica de la memoria para permitir que el grupo de búferes aumente y se reduzca de forma dinámica dentro de los límites configurados en función de las demandas de memoria del sistema. Por lo tanto, no es necesario ajustar el tamaño del pool de búfer. Cuando diagnostiques problemas de rendimiento, las primeras métricas que debes tener en cuenta son la tasa de aciertos del pool de búferes y la tasa de lectura para ver si tu aplicación se beneficia del pool de búferes. Si no es así, significa que el conjunto de datos de la aplicación no cabe en el grupo de búferes, por lo que deberías plantearte cambiar 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 que requiere este proceso, minimiza la cantidad de datos que se deben manipular. Monitoriza la utilización de la CPU en el servidor de la base de datos para asegurarte de que la utilización en estado estable es de aproximadamente el 70%. Esta cantidad deja suficiente margen en el servidor para picos de utilización o cambios en los patrones de acceso a lo largo del tiempo. Si se acerca al 100% de utilización, se introduce una sobrecarga debido a la programación de procesos y al cambio de contexto, lo que puede crear cuellos de botella en otras partes del sistema. El uso elevado de la CPU es otra métrica clave que debes tener en cuenta a la hora de tomar decisiones sobre las especificaciones de las máquinas.
Las operaciones de entrada/salida por segundo (IOPS) son un factor importante en el rendimiento de las aplicaciones de bases de datos, ya que determinan cuántas operaciones de entrada o salida por segundo puede ofrecer 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 en columnas
El motor en columnas acelera el procesamiento de consultas SQL de análisis, combinaciones y agregaciones proporcionando los siguientes componentes:
Almacén de columnas en memoria: contiene datos de tablas y vistas materializadas de 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, define 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, consulte Cambiar los parámetros de configuración.
Planificador de consultas y motor de ejecución en columnas: admite el uso del almacén de columnas en las consultas.
Gestión automática de la memoria
El gestor de memoria automático monitoriza 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é de búfer compartida en función de la presión de la memoria. De forma predeterminada, el gestor 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 a la caché de búfer compartida.
Para cambiar el límite superior del tamaño de la caché de búfer compartida, define el parámetro shared_buffers en el postgresql.conf que utilice tu instancia de AlloyDB Omni.
Para obtener más información, consulta Gestión automática de la memoria.
Autovacuum adaptativo
El vaciado automático adaptativo analiza las operaciones en función de la carga de trabajo de la base de datos y ajusta automáticamente la frecuencia del vaciado. Este ajuste automático ayuda a que la base de datos funcione con un rendimiento óptimo, incluso cuando la carga de trabajo cambia, sin que el proceso de vacío interfiera.
La función de autovacuum adaptativo usa los siguientes factores para determinar la frecuencia y la intensidad de las operaciones de vacío:
- Tamaño de la base de datos
- Número de tuplas inactivas en la base de datos
- Antigüedad de los datos de la base de datos
- Número de transacciones por segundo frente a la velocidad de vacío estimada
El vaciado automático adaptativo ofrece las siguientes ventajas:
- Gestión dinámica de recursos de VACUUM: en lugar de usar un límite de costes fijo, AlloyDB Omni usa estadísticas de recursos en tiempo real para ajustar los procesos de VACUUM. Cuando el sistema está ocupado, se limita el proceso de vacío y el uso de recursos asociado. Si hay suficiente memoria disponible, se asigna memoria adicional a
maintenance_work_mempara reducir el tiempo de limpieza de extremo a extremo. - Limitación dinámica de XID: monitoriza de forma automática y continua el progreso del proceso de limpieza y la velocidad de consumo de los IDs de transacción. Si se detecta un riesgo de envoltura del ID de transacción, AlloyDB Omni ralentiza las transacciones para limitar el consumo de IDs. Además, AlloyDB Omni asigna más recursos a los procesos 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 por segundo se reducen hasta que los IDs de transacción se encuentran en una zona segura (se puede observar como sesiones que esperan en
AdaptiveVacuumNewXidDelay). Cuando aumenta la antigüedad del ID de transacción, los trabajadores de vacío se incrementan de forma dinámica. - Vacío eficiente para tablas más grandes: la lógica predeterminada de PostgreSQL que se usa para decidir cuándo se debe vaciar 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 en tablas pequeñas, pero puede que no lo haga de forma eficiente en tablas más grandes que se actualicen con frecuencia. AlloyDB Omni proporciona un mecanismo de análisis actualizado que ayuda a activar el autovacuum con más frecuencia. Este mecanismo de análisis analiza fragmentos de tablas grandes y elimina las tuplas inactivas de forma más eficiente que la lógica predeterminada de PostgreSQL. - Registrar mensajes de advertencia: en AlloyDB Omni, se detectan los bloqueadores de VACUUM, como las transacciones de larga duración, las transacciones preparadas o los slots de replicación que han perdido sus destinos, y se registran advertencias en los registros de PostgreSQL para que puedas solucionar los problemas a tiempo.
Trabajador de IA y aprendizaje automático
En AlloyDB Omni, el trabajador en segundo plano de IA/ML proporciona todas las funciones necesarias para llamar a modelos de Vertex AI directamente desde la base de datos. El trabajador de IA/ML se ejecuta como un proceso llamado omni ml worker.
Para obtener más información, consulta el artículo sobre cómo crear aplicaciones de IA generativa con AlloyDB AI.
Siguientes pasos
- Consulta las opciones de descarga e instalación de AlloyDB Omni.
- Sigue una guía de inicio rápido para instalar AlloyDB Omni en una VM.
- Realiza una instalación de una sola instancia de AlloyDB Omni en cualquier VM Linux.
- Consulta cómo instalar AlloyDB Omni en Kubernetes.