Compute a demanda de ClickHouse

• 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

• 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.

​

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.

​

Uso de compute bajo demanda

​

Settings

​

Ejemplo

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)

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

​

Consultas concurrentes

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

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

​

Cuando el grupo no puede satisfacer la solicitud

​

Monitoring

​

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';

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

​

Precios

​

Limitaciones

• 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

• 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

• 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

• 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

• 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.

​

FAQ