> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

export const Image = ({img, alt, size = "lg", background}) => {
  const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
  const backgroundColor = background === "white" ? "white" : background === "black" ? "rgb(31 31 28)" : undefined;
  return <div className={`ch-image-${normalizedSize}`}>
      <Frame>
        <img src={img} alt={alt} style={{
    backgroundColor
  }} />
      </Frame>
    </div>;
};

export const PrivatePreviewBadge = () => {
  return <div className="privatePreviewBadge">
            <div className="privatePreviewIcon">
            <svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
                <path d="M5.33301 6.66667V4.66667V4.66667C5.33301 3.194 6.52701 2 7.99967 2V2C9.47234 2 10.6663 3.194 10.6663 4.66667V4.66667V6.66667" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" />
                <path d="M8.00033 9.33337V11.3334" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" />
                <path fillRule="evenodd" clipRule="evenodd" d="M11.333 14H4.66634C3.92967 14 3.33301 13.4033 3.33301 12.6666V7.99996C3.33301 7.26329 3.92967 6.66663 4.66634 6.66663H11.333C12.0697 6.66663 12.6663 7.26329 12.6663 7.99996V12.6666C12.6663 13.4033 12.0697 14 11.333 14Z" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" />
            </svg>
        </div>
            {'Vista previa privada'}
        </div>;
};

<PrivatePreviewBadge />

<Note>
  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](#limitations).

  [Únase a la lista de espera](https://clickhouse.com/cloud/on-demand-compute-waitlist).
</Note>

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](/es/products/cloud/features/infrastructure/warehouses). 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](https://github.com/ClickHouse/ClickHouse/pull/86353) (cost-based optimizer)
* Una nueva [distributed query execution](https://clickhouse.com/blog/multi-stage-distributed-query-execution-clickhouse-cloud)

<h2 id="when-to-use-on-demand-compute">
  Cuándo usar On-Demand Compute
</h2>

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.

<h2 id="how-it-works">
  Cómo funciona
</h2>

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.

<h2 id="using-on-demand-compute">
  Uso de compute bajo demanda
</h2>

<h3 id="settings">
  Settings
</h3>

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`) |

<Tip>
  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.
</Tip>

<h3 id="example">
  Ejemplo
</h3>

Algunas consultas no se pueden distribuir entre los workers:

```sql theme={null}
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`:

```sql theme={null}
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.
```

```sql theme={null}
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.

<h3 id="concurrent-queries">
  Consultas concurrentes
</h3>

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:

```sql theme={null}
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:

```sql theme={null}
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.

<h3 id="pool-capacity">
  Cuando el grupo no puede satisfacer la solicitud
</h3>

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.

<h2 id="monitoring">
  Monitoring
</h2>

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

<h3 id="worker-provided">
  Número de workers asignados
</h3>

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

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

```sql theme={null}
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'
```

<h2 id="available-regions">
  Regiones disponibles
</h2>

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](https://clickhouse.com/cloud/on-demand-compute-waitlist). Habilitaremos más regiones en función de la demanda.

<h2 id="pricing">
  Precios
</h2>

Durante la private preview, On-Demand Compute es gratuito, con un límite de uso (consulte [Limitaciones](#limitations)). 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.

<h2 id="limitations">
  Limitaciones
</h2>

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

<h2 id="roadmap">
  Roadmap
</h2>

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

<h2 id="security">
  Seguridad
</h2>

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.

<h3 id="network-isolation">
  Aislamiento de red
</h3>

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.

<Image img="https://mintcdn.com/private-7c7dfe99-vortex-format/jweE-7zQAicgbBgU/images/cloud/reference/on-demand-compute-worker-isolation.svg?fit=max&auto=format&n=jweE-7zQAicgbBgU&q=85&s=eca0a3627e094e5cb7bb2bb1609d2174" size="lg" alt="Network isolation explanation diagram" width="1320" height="740" data-path="images/cloud/reference/on-demand-compute-worker-isolation.svg" />

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

<h3 id="authentication-and-authorization">
  Autenticación y autorización internas
</h3>

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

<Note>
  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.
</Note>

<h2 id="faq">
  FAQ
</h2>

<AccordionGroup>
  <Accordion title="¿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.
  </Accordion>

  <Accordion title="¿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.
  </Accordion>

  <Accordion title="¿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.
  </Accordion>

  <Accordion title="¿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.
  </Accordion>

  <Accordion title="¿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.
  </Accordion>

  <Accordion title="¿Dónde puedo hacer preguntas?">
    Consulte a su account team; ellos le presentarán al product manager de On-Demand Compute.
  </Accordion>

  <Accordion title="¿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.
  </Accordion>

  <Accordion title="¿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](#network-isolation).
  </Accordion>

  <Accordion title="¿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.
  </Accordion>

  <Accordion title="¿Está disponible en ClickHouse BYOC o ClickHouse Private?">
    No. El private preview no está disponible en ClickHouse BYOC ni en ClickHouse Private.
  </Accordion>
</AccordionGroup>