Compute a demanda de ClickHouse

Añade compute para cargas de trabajo de ClickHouse Cloud sin redimensionar tu primary service. El soporte en private preview se limita a determinadas queries.

On-Demand Compute se encuentra en private preview. No está cubierto por los SLO ni los SLA de ClickHouse Cloud, y pueden aplicarse limitaciones conocidas y desconocidas. Consulte Limitaciones.

Únase a la lista de espera.

On-Demand Compute es una capability de ClickHouse Cloud que proporciona a su cloud service (un tenant) capacidad adicional e instantánea para las cargas de trabajo compatibles, sin necesidad de redimensionar ni aprovisionar otro service. Este trabajo se ejecuta en workers de ClickHouse ajenos al compute propio de su service. Los workers provienen de un grupo gestionado que se comparte entre tenants de la misma región, pero cada worker se asigna a un único tenant a la vez.

Durante el private preview, On-Demand Compute solo admite consultas SELECT. Usted habilita una consulta mediante settings a nivel de consulta, session o usuario, y ClickHouse asigna workers del grupo para ejecutarla a través de su service y su endpoint existentes.

Esto se diferencia de la separación de cómputo-cómputo. Un warehouse proporciona compute dedicado y de larga duración mediante varios services que comparten datos. On-Demand Compute proporciona workers temporales de un grupo compartido a través de su service existente.

On-Demand Compute aprovecha capabilities completamente nuevas:

• Ejecución de consultas stateless con on-demand compute
• Un nuevo CBO (cost-based optimizer)
• Una nueva distributed query execution

​

Cuándo usar On-Demand Compute

Durante la private preview, use On-Demand Compute para las consultas SELECT elegibles y de uso intensivo de compute que desee ejecutar fuera del compute del primary service:

• Consultas ad hoc y analíticas: ejecute consultas SELECT de uso intensivo de compute en workers adicionales.
• Cargas de trabajo de lectura no críticas: traslade determinadas lecturas fuera del primary service.
• Consultas sobre lagos de datos: consulte datos compatibles de Apache Iceberg, Delta Lake o SharedMergeTree en workers adicionales.
• Compute adicional temporal: solicite workers para consultas elegibles sin redimensionar el primary service.

La private preview solo admite consultas SELECT. Los workers no ejecutan consultas INSERT, DDL, mutations ni background operations.

​

Cómo funciona

1. Envías una consulta SELECT elegible a tu ClickHouse Cloud service solicitando un número específico de workers. Tu endpoint, la authentication y la configuración de RBAC no cambian
2. Tu cluster se conecta entonces al grupo y solicita el número de workers especificado
3. Los workers se arriendan durante al menos 60 segundos; si la consulta dura más, el lease se renueva automáticamente
4. Los workers reciben la consulta y la ejecutan
5. La respuesta se devuelve a tu client
6. Los workers se borran.

Durante el private preview, cada worker cuenta con 8 vCPUs y 32 GiB de memoria. Usa distributed_plan_workers_num para especificar cuántos workers solicita la consulta.

​

Uso de compute bajo demanda

​

Settings

Utilice estos ajustes para empezar a usar on-demand compute:

Ajuste	Valor requerido	Propósito
make_distributed_plan	Yes	Habilita el distributed query plan experimental. Necesario para On-Demand Compute.
distributed_plan_workers_num	Yes	Número de workers que se van a arrendar para esta consulta. Si es 0 (el valor predeterminado), la consulta se ejecuta en su servicio y no en el grupo de workers.
enable_parallel_replicas	Yes (establecido en 0)	Las parallel replicas no son compatibles con el distributed plan.
distributed_plan_fallback_to_local_execution	No (predeterminado en 0)	Ajuste para recurrir a la ejecución local cuando un plan no se puede distribuir (solo tiene efecto con make_distributed_plan)

Durante la versión preliminar, defina los ajustes a nivel de consulta o cree un usuario aparte con ajustes distintos. De este modo queda claro qué sentencias usan On-Demand Compute.

​

Ejemplo

Algunas consultas no se pueden distribuir entre los workers:

SELECT count()
FROM nyctaxi.trips
SETTINGS distributed_plan_fallback_to_local_execution = 0, make_distributed_plan = 1, distributed_plan_workers_num = 5

Query id: c1c96ede-0c4c-414f-b103-f27f0b7d34c7


Elapsed: 0.992 sec.

Received exception from server (version 26.9.1):
Code: 344. DB::Exception: Received from nuqae0jhz5.eu-west-1.aws.clickhouse-staging.com:9440. DB::Exception: make_distributed_plan cannot distribute this query: it contains the step ReadFromPreparedSource which could not execute remotely. (SUPPORT_IS_DISABLED)

Para asegurarse de que las consultas recurran a la ejecución local, puede usar la siguiente configuración: distributed_plan_fallback_to_local_execution:

SELECT count()
FROM nyctaxi.trips
SETTINGS distributed_plan_fallback_to_local_execution = 1, make_distributed_plan = 1, distributed_plan_workers_num = 5

Query id: c7b09855-e3c3-40ef-9790-5374e0726f26

   ┌─count()─┐
1. │   21932 │
   └─────────┘

1 row in set. Elapsed: 0.896 sec.

SELECT
    sum(l_extendedprice * l_discount) AS revenue
FROM lineitem
WHERE
    l_shipdate >= DATE '1994-01-01'
    AND l_shipdate < DATE '1994-01-01' + INTERVAL 1 YEAR
    AND l_discount BETWEEN 0.06 - 0.01 AND 0.06 + 0.01
    AND l_quantity < 24
SETTINGS
    make_distributed_plan = 1,
    distributed_plan_workers_num = 5,
    enable_parallel_replicas = 0

Esta consulta solicita cinco workers. La cantidad de workers que proporciona ClickHouse depende del límite de la vista previa privada y de la capacidad disponible del grupo.

​

Consultas concurrentes

Las consultas concurrentes de un mismo ClickHouse Cloud service pueden compartir los workers asignados. ClickHouse solicita workers adicionales únicamente cuando una consulta necesita más workers de los que ya están asignados al service.

Por ejemplo, si dos consultas concurrentes solicitan tres workers cada una, pueden compartir esos mismos tres workers. Si otra consulta solicita cinco workers, ClickHouse puede usar los tres workers asignados y solicitar dos más al grupo.

Vea el siguiente ejemplo:

SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 3, ...;
SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 3, ...;

Ambas comparten los mismos tres workers.

Si una tercera consulta concurrente solicita cinco workers:

SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 5, ...;

Esa consulta se ejecuta en los tres workers existentes más dos workers recién adquiridos en lease.

​

Cuando el grupo no puede satisfacer la solicitud

La disponibilidad de workers no está garantizada durante la private preview. Si hay menos workers disponibles de los solicitados, la consulta se ejecuta con los workers que ClickHouse pueda asignar. Por ejemplo, una solicitud de cinco workers puede ejecutarse con tres.

Si no se puede arrendar ningún worker, la consulta falla.

Reintente la consulta. Si el problema persiste, póngase en contacto con el equipo de su cuenta de ClickHouse: es posible que el grupo de vista previa esté agotado o mal dimensionado.

​

Monitoring

Utiliza system.query_log en tu service para saber cuántos workers se asignaron a tu consulta.

​

Número de workers asignados

SELECT
    ProfileEvents['StatelessWorkerRequested'],
    ProfileEvents['StatelessWorkerProvided']
FROM clusterAllReplicas(default, system.query_log)
WHERE query_id = '<YOUR_QUERY_ID>'
  AND type != 'QueryStart';

Establezca log_comment = 'on-demand' (o el nombre de un workload) en las consultas On-Demand para poder filtrarlas sin necesidad de analizar Settings.

SELECT
    sum(l_extendedprice * l_discount) AS revenue
FROM lineitem
WHERE
    l_shipdate >= DATE '1994-01-01'
    AND l_shipdate < DATE '1994-01-01' + INTERVAL 1 YEAR
    AND l_discount BETWEEN 0.06 - 0.01 AND 0.06 + 0.01
    AND l_quantity < 24
SETTINGS
    make_distributed_plan = 1,
    distributed_plan_workers_num = 5,
    enable_parallel_replicas = 0,
    log_comment = 'on-demand-private-preview'

​

Regiones disponibles

On-Demand Compute es regional: los workers se ejecutan en la misma región que su servicio.

Cloud	Región	Notas
AWS	us-east-1
AWS	eu-west-1

Si su región no aparece, solicítela en la lista de espera. Habilitaremos más regiones en función de la demanda.

​

Precios

Durante la private preview, On-Demand Compute es gratuito, con un límite de uso (consulte Limitaciones). Consulte a su account team de ClickHouse si necesita ampliar ese límite.

Los precios se aplicarán cuando finalice la preview. Se notificará a los participantes de la preview antes de que la feature pase a beta y antes de que se apliquen cargos.

El modelo previsto es el mismo que el del compute de ClickHouse Cloud: se paga por el compute que se utiliza (tiempo de worker en lease), no por los datos escaneados ni por las filas leídas.

​

Limitaciones

Durante la private preview se aplican las siguientes limitaciones. Pueden existir otras. Informe de cualquier comportamiento inesperado al soporte de ClickHouse o a su account team.

• Solo consultas SELECT. Los workers no ejecutan consultas INSERT, mutations, DDL ni background operations.
• Formato compatible. La private preview admite Apache Iceberg, Delta Lake y SharedMergeTree.
• Parallel replicas. Las parallel replicas deben estar deshabilitadas.
• Tamaño del worker. Cada worker cuenta con 8 vCPUs y 32 GiB de memoria.
• Límite de workers. Cada consulta puede solicitar hasta cinco workers durante la private preview.
• Capacidad del grupo. La disponibilidad de workers no está garantizada. Una consulta puede recibir menos workers de los solicitados. Si no hay workers disponibles, la consulta falla.
• Rendimiento. El rendimiento varía según la consulta. La asignación de workers, la planificación distribuida y la transferencia de las etapas del plan pueden añadir latency. Algunas formas de consulta pueden rendir peor que si se ejecutaran en el primary service (sus consultas habituales de menos de un segundo probablemente rendirán mejor en su cluster)
• Compatibilidad de consultas. El distributed planner no puede ejecutar de forma remota todos los query plans. Las consultas no compatibles pueden devolver una excepción SUPPORT_IS_DISABLED.

​

Roadmap

On-Demand Compute es un punto de partida. Trabajos en curso o previstos:

• Resolver las limitaciones conocidas (huecos de SUPPORT_IS_DISABLED)
• Grupos de workers de distintos tamaños
• Estabilizar el rendimiento de las consultas frente a la ejecución stateful
• Compatibilidad con fusiones en segundo plano
• Precios
• Calibración del autoscaler del grupo de workers
• Observabilidad integrada
• Permisos dedicados para On-Demand Compute
• Ampliación de las cargas de trabajo de lago de datos (escritura, compaction, etc…)

​

Seguridad

Los workers provienen de un grupo precalentado que se comparte entre los services de una misma región, por lo que existe una regla no negociable: un worker atiende a un único service a la vez y nunca se traspasa de un service a otro.

La forma de acceder a ClickHouse no cambia en absoluto. Los clients siguen conectándose a su service endpoint con la authentication que ya utilizan, y su service es lo único que se comunica con los workers en su nombre. Los workers no exponen ningún endpoint al cliente.

• Un service por worker: un worker se asigna en lease a un único service mientras dure ese lease. Nunca lo comparten dos services al mismo tiempo.
• Sin reutilización entre services: cuando finaliza un lease, el worker se destruye y se sustituye por uno nuevo. Un worker nunca se reasigna a otro service.
• Sin datos persistentes: los workers no conservan almacenamiento persistente ni sobreviven al final de un lease.
• La misma región que su service: los workers se ejecutan en la misma región que el service que los toma en lease, conforme a estrictas reglas de residencia de datos.
• Sus access controls existentes siguen vigentes: las IP access lists y los private endpoints rigen su service endpoint exactamente igual que antes. On-Demand Compute no añade ningún endpoint que deba configurar o proteger.
• Su authentication y RBAC actuales: las consultas se ejecutan con el mismo USER y los mismos privileges que cualquier otra consulta de su service. Los workers no tienen una identity ni un modelo de permission propios.

​

Aislamiento de red

Mientras un worker está arrendado a tu service, la plataforma permite el tráfico de red entre ese worker y tu service, y bloquea todo lo demás. La restricción se aplica en la capa de red y no en el query engine, por lo que no depende de la consulta, de sus settings ni del plan que genere el optimizer.

• Solo tu service puede alcanzar tus workers. El path existe para el lease actual del worker y únicamente para ese service.
• Los workers sin asignar son inalcanzables. Un worker que espera en el grupo no tiene ninguna ruta de red hacia o desde ningún service hasta que se arrienda.
• Los workers arrendados a distintos services no pueden comunicarse entre sí. Los workers de un mismo lease intercambian entre ellos plan stages y resultados intermedios. Los workers de leases distintos permanecen aislados entre sí, aunque compartan un grupo.
• El path se elimina junto con el worker. Finalizar un lease destruye el worker, con lo que desaparece lo único que el tráfico tenía permitido alcanzar.
• El path de las requests se mantiene acotado. Tu service se comunica con el servicio de asignación de workers para arrendar y renovar workers. Ese path no transporta datos de consultas y se limita a la assignment API.

​

Autenticación y autorización internas

El aislamiento de red determina qué puede llegar a un worker. La autenticación determina qué se le permite hacer a un llamador una vez que llega allí, y ambos mecanismos se aplican de forma independiente: un llamador debe cumplir con los dos.

Cada connection entre su service, el servicio de asignación de workers y los workers está autenticada. No se confía en nada: todas las credenciales las emite la plataforma y se entregan por lease.

• Una credencial por worker: cuando se otorgan workers en lease a su service, la plataforma emite un token firmado y único para cada uno. Cada token funciona únicamente para ese worker y únicamente para su service.
• De corta duración y vinculados al lease: los tokens caducan junto con el lease que los generó. Al renovar un lease se emiten tokens nuevos y, una vez finalizado un lease, sus tokens ya no autentican nada.
• Verificados contra la plataforma: un worker valida el token que se le presenta contra el servicio de identity de la plataforma, en lugar de confiar en los datos suministrados en la request.

Connection	Qué se autentica
Su service → servicio de asignación de workers	La identity de plataforma de su service, que determina sobre qué leases puede actuar.
Su service → un worker otorgado en lease	Un token firmado cuyo alcance se limita a ese único worker, durante la vigencia del lease.
Worker → worker dentro de un mismo lease	La propia identity de plataforma de cada worker, más una comprobación de que el llamador aún mantiene un lease vigente sobre el worker receptor.

Estas credenciales son internas al modo en que ClickHouse Cloud ejecuta su consulta. Nunca se exponen a sus clients y no guardan relación con la forma en que usted se autentica en ClickHouse: los clients siguen conectándose con sus credenciales existentes, y los privilegios de consulta continúan regidos por el RBAC de su service.

​

FAQ

¿On-Demand Compute es open source?

No. Se trata de una arquitectura de ClickHouse Cloud: ClickHouse server (distributed plan), data plane (grupo de workers y leases) y control plane. La configuración experimental make_distributed_plan y el CBO existen en ClickHouse OSS, pero el grupo compartido de workers y la ejecución stateless son exclusivos de Cloud.

¿Necesito una versión específica para unirme al private preview?

Sí. La versión utilizada durante el private preview será una compilación personalizada. Es posible que se requieran actualizaciones adicionales durante el preview.

¿Cómo será el pricing?

Por el momento no tenemos un pricing público que compartir, pero el uso de la funcionalidad es gratuito durante el private preview. Dicho esto, la filosofía de pricing será la misma que la de ClickHouse Cloud: cobrar por el compute utilizado, no por los datos escaneados ni por las filas leídas. Las tarifas exactas se publicarán antes de que se aplique el pricing.

¿Puedo usar esto en production?

Puede ejecutar cargas de trabajo reales, pero se trata de un private preview: existen limitaciones conocidas y desconocidas, y no hay SLO/SLA para la availability del grupo de workers.

¿En qué se diferencia esto del autoscaling de mi service?

El autoscaling modifica el compute asignado a su primary service. Durante el private preview, On-Demand Compute otorga a las SELECT queries elegibles acceso temporal a workers de un grupo administrado sin cambiar el tamaño del primary service. El autoscaling gestiona la capacidad continua del service, mientras que On-Demand Compute proporciona compute temporal para cargas de trabajo específicos.

¿Dónde puedo hacer preguntas?

Consulte a su account team; ellos le presentarán al product manager de On-Demand Compute.

¿Dónde puedo informar errores?

Abra un ticket de Support (severidad 3) o repórtelo al product manager. Incluya el query_id, su Service ID y la excepción completa.

¿Puede otro ClickHouse Cloud service acceder a los workers que ejecutan mi query?

No. Mientras un worker está asignado mediante lease a su service, la plataforma solo permite el tráfico entre ese worker y su service, y lo bloquea para todos los demás services. Los workers sin asignar y los workers asignados a otro service no tienen ninguna ruta de red hacia el suyo. Consulte Aislamiento de red.

¿Otro service reutiliza un worker después de que mi query finaliza?

No. Cuando finaliza un lease, el worker se destruye y se reemplaza por uno nuevo en lugar de traspasarse al siguiente service.

¿Está disponible en ClickHouse BYOC o ClickHouse Private?

No. El private preview no está disponible en ClickHouse BYOC ni en ClickHouse Private.