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 de PostgreSQL escalable y de alto rendimiento, pero no puedes ejecutar una base de datos en la nube debido a requisitos reglamentarios o de soberanía de los datos.
- Necesitas una base de datos que siga funcionando incluso cuando se desconecta de Internet.
- Para minimizar la latencia, debes ubicar tu base de datos lo más cerca posible de tus usuarios.
- Deseas migrar de una base de datos heredada, pero sin comprometerte con 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 de la misma manera que lo harías con cualquier otra importación de datos inicial.
Características clave
- Un servidor de bases de datos compatible con PostgreSQL
- Se agregó compatibilidad con AlloyDB AI, que te ayuda a crear aplicaciones de IA generativa de nivel empresarial con tus datos operativos.
- Integraciones con el Google Cloud ecosistema de IA, incluido Vertex AI Model Garden y herramientas de IA generativa de código abierto
Compatibilidad con las funciones de piloto automático de AlloyDB para PostgreSQL enGoogle Cloud , lo que permite que AlloyDB Omni se administre y ajuste por sí mismo.
Por ejemplo, AlloyDB Omni admite la administración automática de memoria y el autovacuum adaptable de datos obsoletos.
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 comunican con tu instalación de AlloyDB Omni, al igual que las aplicaciones se conectan y comunican con un servidor de base de datos de PostgreSQL estándar. El control de acceso del usuario también se basa en los estándares de PostgreSQL.
Desde el registro hasta el proceso de limpieza y el 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 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 presentan las siguientes ventajas:
- Administración transparente de dependencias: Todas las dependencias necesarias se incluyen en el contenedor y Google las prueba para garantizar que sean totalmente compatibles con AlloyDB Omni.
- Portabilidad: Puedes esperar que AlloyDB Omni funcione de manera coherente en todos los entornos.
- Aislamiento de seguridad: Tú eliges a qué puede acceder 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 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 copias de seguridad y recuperación que te permite crear un nuevo clúster de base de datos 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 un clúster de base de datos de AlloyDB Omni a partir de una copia de seguridad 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 Crea una copia de seguridad y restablece 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 promover un clúster de base de datos secundaria 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, la capa de infraestructura en la que 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 satisfacer la consulta
- Realiza cualquier filtrado, ordenamiento y 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 dirige 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 usos futuros.
Los recursos que se usan cuando se procesa la búsqueda del cliente incluyen CPU, memoria, E/S, red y primitivas de sincronización, como bloqueos de bases de datos. El ajuste del rendimiento tiene como objetivo optimizar el uso de recursos durante cada uno de los pasos de la ejecución de la consulta.
El objetivo de un motor de base de datos con buen rendimiento es responder a una consulta con la menor cantidad de recursos posible. Este objetivo comienza con un buen diseño de consultas y modelos de datos.
- ¿Cómo se pueden responder las preguntas con la menor cantidad de datos posible?
- ¿Qué índices se necesitan para reducir el espacio de búsqueda y la E/S?
- Ordenar los datos requiere CPU y, a menudo, acceso al disco para grandes conjuntos de datos, 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 búfer. Si las páginas que contienen los datos requeridos no se encuentran en el búfer, AlloyDB Omni las lee del sistema de archivos. Acceder a los datos desde el grupo de búferes es mucho más rápido que leer desde el sistema de archivos, por lo que 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 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 búfer. 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 se beneficia del grupo de búferes. Si no es así, significa que el conjunto de datos de la aplicación no cabe en el búfer de memoria y 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 suficiente espacio en el servidor para los picos de uso o los cambios en los patrones de acceso con el tiempo. Ejecutar el sistema cerca del 100% de utilización introduce una sobrecarga debido a la programación de procesos y el cambio de contexto, y podría crear cuellos de botella en otras partes del sistema. El uso elevado de la 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, ya que indican cuántas operaciones de entrada o salida por segundo puede proporcionar 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, ya que proporciona los siguientes componentes:
Almacén de columnas en 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 Cómo cambiar los parámetros de configuración.
Planificador de consultas y motor de ejecución basados en 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 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 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 a la caché de búfer compartido.
Para cambiar el límite superior del tamaño de la caché de búfer compartida, 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 memoria.
Autovacuum adaptable
La aspiración automática adaptable analiza las operaciones según 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 funcione con el máximo rendimiento, incluso cuando cambia la carga de trabajo, sin interferencias del proceso de vacío.
El autovacuum adaptable usa los siguientes factores para determinar la frecuencia y la intensidad de las operaciones de vacuum:
- 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 estimada de VACUUM
El autovacuum adaptable proporciona los siguientes beneficios:
- Administración dinámica de recursos de vacío: En lugar de usar un límite de costos fijo, AlloyDB Omni usa estadísticas de recursos en tiempo real para ajustar los trabajadores de vacío. 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 para
maintenance_work_memy, así, se reduce el tiempo de vacío de extremo a extremo. - Limitación dinámica de XID: Supervisa de forma automática y continua el progreso de la limpieza y la velocidad del consumo de IDs de transacción. Si se detecta un riesgo de ajuste del 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 vacuum para procesar las tablas que bloquean el avance y la liberación del espacio de IDs 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 (se pueden observar como sesiones en espera en
AdaptiveVacuumNewXidDelay). Cuando aumenta la antigüedad del ID de transacción, se incrementan de forma dinámica los trabajadores de vacío. - Aspirado 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 y que se actualicen con frecuencia. AlloyDB Omni proporciona un mecanismo de análisis actualizado que ayuda a activar autovacuum con mayor frecuencia. Este mecanismo de análisis explora 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 VACUUM, como las transacciones de larga duración, las transacciones preparadas o las ranuras 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 AA/IA 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 más información sobre las opciones de descarga e instalación de AlloyDB Omni.
- Realiza un 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.