Skip to main content
ClickHouse Managed Postgres ofrece opciones de escalado flexible para adaptarse a las necesidades de su carga de trabajo. Con más de 50 tipos de instancia con almacenamiento NVMe entre los que elegir, puede escalar CPU, memoria y almacenamiento de forma independiente para optimizar el rendimiento y el costo según su caso de uso específico.

​
Tipos de instancia y flexibilidad

ClickHouse Managed Postgres ofrece una amplia variedad de tipos de instancia, cada uno optimizado para distintas cargas de trabajo:
  • Más de 50 tipos de instancia disponibles en configuraciones optimizadas para cómputo, memoria y almacenamiento
  • Almacenamiento basado en NVMe en todos los tipos de instancia para ofrecer una E/S de disco uniforme y de alto rendimiento
  • Escalado independiente de recursos: elige el equilibrio adecuado entre CPU, memoria y almacenamiento según tu carga de trabajo

​
Cómo elegir el tipo de instancia adecuado

Las distintas cargas de trabajo se benefician de diferentes configuraciones de recursos:
Por motivos de seguridad, es posible que no puedas cambiar a tipos de instancia cuyo almacenamiento se aproxime a tu capacidad de almacenamiento actualmente utilizada. Elige siempre tipos de instancia con holgura respecto a tu capacidad utilizada actual para evitar problemas.

​
Cómo funciona el escalado

Cuando cambias de tipo de instancia, ClickHouse Managed Postgres realiza una operación de escalado vertical que aprovisiona nueva infraestructura y migra tu base de datos con un tiempo de inactividad mínimo.

​
Proceso de escalado

El flujo de escalado aprovisiona una nueva instancia standby a partir de backups y realiza un failover controlado:
  1. Aprovisionamiento de la instancia standby: Se crea una nueva instancia standby con el tipo de instancia de destino (CPU, memoria y configuración de almacenamiento)
  2. Restauración desde backups de S3: La instancia standby se inicializa restaurando el backup más reciente almacenado en S3
  3. Reproducción paralela del WAL: La instancia standby aplica todos los cambios del Write-Ahead Log (WAL) desde el backup mediante mecanismos de restauración en paralelo impulsados por WAL-G
    • WAL-G permite operaciones de restauración rápidas y paralelas
    • El creador de WAL-G forma parte del equipo de Ubicloud, con el que nos hemos asociado, lo que garantiza un alto nivel de experiencia y optimización
  4. Sincronización de la replicación: La instancia standby se sincroniza con la instancia primaria transmitiendo y aplicando los cambios continuos del WAL
  5. Failover: Una vez que la instancia standby está completamente sincronizada, un failover controlado la promueve a la nueva primaria
    • Este es el único paso que causa tiempo de inactividad (~30 segundos)
    • Todas las conexiones activas se interrumpen durante el failover
    • Los clientes deben volver a conectarse una vez finalizado el failover
  6. Retirada de la instancia antigua: La instancia original se retira una vez finalizado el failover

​
Duración del escalado

El tiempo total necesario para el escalado depende principalmente del tamaño de su base de datos y de la cantidad de datos de WAL que deban reproducirse desde los backups:
  • Restauración del backup: Tiempo necesario para restaurar el full backup más reciente desde S3 en la nueva instancia
  • Reproducción de WAL: Tiempo necesario para reproducir los cambios incrementales de WAL desde el último full backup
  • Restauración en paralelo: Los mecanismos de restauración en paralelo de WAL-G aceleran significativamente el proceso
El tiempo de restauración puede variar de unos minutos a varias horas, pero el mantenimiento/tiempo de inactividad es muy bajo (solo ~30 segundos).
Tiempo de inactividad mínimoSu aplicación experimentará aproximadamente 30 segundos de tiempo de inactividad durante el failover, independientemente de cuánto dure el proceso general de escalado. Todo el trabajo de restauración y puesta al día se realiza en segundo plano en la instancia standby.

​
Restauración en paralelo con WAL-G

ClickHouse Managed Postgres usa WAL-G para acelerar la restauración de backups durante las operaciones de escalado. Cabe destacar que el creador de WAL-G forma parte del equipo de Ubicloud, con el que nos hemos asociado, lo que aporta una gran experiencia al proceso de restauración. WAL-G proporciona:
  • Descarga y descompresión en paralelo: varios segmentos del backup se recuperan de S3 y se descomprimen simultáneamente
  • Reproducción eficiente de WAL: los cambios incrementales del WAL se aplican en paralelo cuando es posible
  • Streaming optimizado: streaming directo desde el almacenamiento S3 sin copias intermedias
  • Restauración rápida: aunque el tiempo total depende del tamaño de los datos, el enfoque en paralelo hace que el proceso sea bastante rápido
Estas optimizaciones reducen significativamente el tiempo necesario para poner en marcha la nueva instancia standby. Y, lo más importante, la restauración se realiza por completo en segundo plano: la aplicación solo experimenta tiempo de inactividad durante la breve ventana de failover de ~30 segundos.

​
Iniciar una operación de escalado

Para escalar su instancia de ClickHouse Managed Postgres:
  1. Vaya a la pestaña Configuración de su instancia
  2. En la sección Escalado, desplácese hasta Tamaño del servicio
  3. Seleccione el tipo de instancia de destino
  4. Revise los cambios y haga clic en “Aplicar cambios”

​
Estrategias de escalado

​
Escalado vertical

El escalado vertical (cambiar los tipos de instancia) es el método principal para ajustar los recursos en ClickHouse Managed Postgres. Este enfoque ofrece:
  • Control granular: Elija entre más de 50 tipos de instancia para ajustar con precisión la CPU, la memoria y el almacenamiento
  • Optimización de la carga de trabajo: Seleccione configuraciones optimizadas para su carga de trabajo específica (intensiva en cómputo, memoria o almacenamiento)
  • Eficiencia de costos: Pague solo por los recursos que necesita, sin sobredimensionar

​
Réplicas de lectura para el escalado horizontal

Para cargas de trabajo con muchas lecturas, considere usar réplicas de lectura para escalar horizontalmente la capacidad de lectura:
  • Desvíe las consultas de lectura a instancias de réplica de lectura dedicadas
  • Cada réplica de lectura es una instancia de Postgres totalmente independiente con su propia capacidad de cómputo y memoria
  • Las réplicas de lectura obtienen en streaming los cambios del WAL desde el almacenamiento de objetos para una replicación eficiente
Este enfoque es ideal para aplicaciones con una alta proporción de lecturas frente a escrituras, como paneles de informes, consultas analíticas o endpoints de API con uso intensivo de lectura.

​
Escalado de CDC para la integración de ClickHouse

Si estás replicando datos a ClickHouse mediante ClickPipes, puedes escalar de forma independiente el pipeline de CDC (captura de datos modificados):
  • Escala los workers de CDC de 1 a 24 núcleos de CPU
  • La memoria se escala automáticamente a 4 veces la cantidad de núcleos de CPU
  • Ajusta el escalado mediante la OpenAPI de ClickPipes
Esto te permite optimizar el rendimiento de la replicación por separado de los recursos de tu instancia de Postgres.

​
Escalado automático

ClickHouse Managed Postgres supervisa el uso de disco y escala el almacenamiento automáticamente para evitar que su instancia se quede sin espacio:
  • 85 % de uso de disco: Recibe una notificación a través de la consola de Cloud y por correo electrónico.
  • 90 % de uso de disco: Se inicia el escalado automático. El almacenamiento aumenta al siguiente tamaño disponible para la familia de instancias correspondiente. La CPU y la memoria se mantienen igual, salvo que el tamaño actual de la instancia no admita un disco más grande; en ese caso, también se aumenta el tamaño de la instancia. Las réplicas de lectura se escalan junto con la instancia primaria.
  • 95 % de uso de disco: La conmutación se realiza en cuanto el nuevo servidor está listo, sin ninguna espera.
Si su instancia ya cuenta con la configuración más grande disponible, el escalado automático no puede ampliarla más. Libere espacio en disco o póngase en contacto con soporte.

​
Conmutación y conexiones

El almacenamiento no se redimensiona in situ. El escalado automático sigue el mismo proceso de escalado que un cambio manual del tipo de instancia: se aprovisiona un servidor de reemplazo con más almacenamiento, se restaura a partir del backup más reciente, se pone al día con el WAL y una conmutación controlada lo promueve a servidor primario. Las instancias con alta disponibilidad obtienen instancias standby de reemplazo con el nuevo tamaño como parte de la misma operación. La conmutación es el único paso que implica tiempo de inactividad, normalmente de menos de un minuto. Una ventana de actualización programada configurada no la retrasa: la ventana se aplica al mantenimiento de la plataforma, no al escalado. Durante la conmutación, se cierran las conexiones abiertas y se revierten las transacciones en curso. La cadena de conexión no cambia: se actualiza el DNS para que apunte al nuevo servidor primario y las aplicaciones con lógica de reconexión estándar se recuperan automáticamente.

​
Modo de solo lectura

Si las operaciones de escritura llenan el disco más rápido de lo que tarda en completarse el escalado automático, la instancia pasa a modo de solo lectura para evitar que el disco se llene por completo. El desencadenante es el espacio libre restante: Las lecturas siguen funcionando, mientras que las operaciones de escritura generan el error estándar de Postgres cannot execute INSERT in a read-only transaction. Si el espacio libre sigue reduciéndose, se cierran las conexiones existentes para que cada sesión aplique la configuración de solo lectura; las lecturas vuelven a funcionar cuando los clientes se reconectan. El modo de solo lectura se desactiva automáticamente cuando se recupera el espacio libre, normalmente justo después de completarse la transición del scale-up.

​
Ejemplo

Una instancia con 1024 GB de almacenamiento ejecuta una carga de trabajo con un uso intensivo de escritura:
  1. Cuando se utilizan 870 GB (85 %), recibe una notificación de almacenamiento.
  2. Cuando se utilizan 922 GB (90 %), se inicia el escalado automático. Se aprovisiona un servidor de reemplazo con 2048 GB de almacenamiento y se restaura a partir del backup más reciente mientras la instancia sigue atendiendo tráfico.
  3. Cuando el reemplazo se ha puesto al día, se realiza la conmutación. Las conexiones se interrumpen durante menos de un minuto, la aplicación se vuelve a conectar al mismo hostname y el uso vuelve a situarse en torno al 45 %.
  4. Si el espacio libre cae por debajo del 2 % (unos 20 GB) antes de que se complete la conmutación, la instancia pasa a modo de solo lectura. Las escrituras se reanudan automáticamente cuando finaliza la conmutación al disco más grande.

​
Recursos adicionales

Última modificación el 26 de agosto de 2026