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

# Elegir un servicio para tu carga de trabajo

> Elige servicios de ClickHouse o Postgres dentro de ClickHouse Cloud para analítica o transacciones, Managed ClickStack para observabilidad, o chDB para análisis local.

Empieza por las consultas y los requisitos de corrección que tu aplicación debe cubrir. Un número elevado de filas por sí solo no determina la base de datos, y una aplicación que genera informes puede incluir cargas de trabajo tanto analíticas como transaccionales.

ClickHouse Cloud es la plataforma de servicios gestionados e incluye ClickHouse para analítica y ClickHouse Managed Postgres para cargas de trabajo transaccionales. Estos servicios ejecutan motores de base de datos distintos —ClickHouse y PostgreSQL— con comportamientos de SQL diferentes. Puedes usar cualquiera de los dos servicios de forma independiente o combinarlos dentro de ClickHouse Cloud.

<h2 id="workload-map">
  Asignar la carga de trabajo a un punto de partida
</h2>

| Lo que necesita tu aplicación | Empieza evaluando | Qué comprobar antes de elegir |
| - | - | - |
| Agregaciones, filtrado y comparaciones sobre grandes historiales de eventos o resultados | [ClickHouse service en ClickHouse Cloud](/es/products/cloud/getting-started/intro) | Consultas representativas, lotes de ingestión, actualidad de los datos, consultas concurrentes y el diseño de las actualizaciones o los reintentos |
| Estado transaccional de la aplicación, como pedidos, reservas de inventario o trabajos cuyas transiciones de estado requieren transacciones y restricciones | [ClickHouse Managed Postgres en ClickHouse Cloud](/es/products/managed-postgres/overview) | Los límites de las transacciones, las restricciones, los índices, la gestión de conexiones y las funcionalidades admitidas y la disponibilidad del service |
| Estado transaccional de la aplicación junto con consultas analíticas que requieren un sistema de servicio independiente | [Services de Postgres y ClickHouse en ClickHouse Cloud](/es/products/managed-postgres/sync-to-clickhouse/clickpipes) | Qué tablas necesitan replicación, el retraso de replicación aceptable, los cambios de esquema y el coste y la operación de dos services |
| Una experiencia gestionada para buscar e investigar logs, métricas y trazas de aplicaciones | [Managed ClickStack](/es/clickstack/getting-started/managed) | La instrumentación, la ingestión de telemetría, la retención y los flujos de trabajo de observabilidad que necesita tu equipo |
| Análisis de archivos o datos en memoria dentro de una aplicación local o un notebook | [chDB](/es/chdb/index) | Los recursos locales y si necesitas un servicio de base de datos compartido y alojado por separado |

Consulta la documentación del producto enlazada para conocer la disponibilidad, las regiones y las limitaciones actuales. ClickHouse Managed Postgres se encuentra actualmente en beta pública; consulta su [guía de inicio rápido](/es/products/managed-postgres/quickstart).

Para un ClickHouse server autogestionado u otras opciones locales, consulta los [modos de despliegue](/es/get-started/about/deployment-modes).

<h2 id="report-results-and-history">
  Ejemplo: resultados de informes e historial de ejecuciones
</h2>

Supongamos que una aplicación procesa archivos subidos, genera informes y necesita conservar resultados consultables y un historial de ejecuciones. Antes de elegir una base de datos, conviene distinguir las filas de resultados de los registros de ejecución:

* **Resultados:** ¿Las consultas recuperan unas pocas filas de un solo informe o agregan datos de muchos informes, datasets e intervalos de tiempo? ¿Qué tabla se prevé que alcance cientos de millones de filas?
* **Registros de ejecución:** ¿Se escribe un único registro inmutable al finalizar una ejecución o la aplicación necesita coordinar la propiedad de jobs activos y las transiciones de estado?
* **Corrección:** ¿Deben modificarse varios registros en una misma transacción? ¿Debe la base de datos imponer la unicidad o impedir que dos workers reclamen el mismo job?
* **Actualidad de los datos:** ¿Con qué rapidez debe ser visible una escritura correcta? ¿Pueden las consultas tolerar una copia analítica incompleta o desfasada?

<h3 id="completed-runs">
  Ejecuciones completadas y resultados analíticos
</h3>

Un ClickHouse service en ClickHouse Cloud es una opción candidata cuando la carga de trabajo dominante es el análisis de filas de resultados y los registros de ejecución pueden añadirse al finalizar. Una tabla pequeña de metadata no justifica por sí sola una segunda base de datos.

Diseñe y pruebe cómo los lectores distinguen una ejecución completa de una ingestada parcialmente. Defina identificadores de ejecución estables, el comportamiento de reintento y cómo se gestionan las filas de resultados duplicadas. Los inserts independientes en una tabla de resultados y en una tabla de historial de ejecuciones no deben tratarse como una única transacción entre tablas.

Si almacena varias versiones de un registro de ejecución, defina cómo las consultas seleccionan la versión actual. [ReplacingMergeTree](/es/reference/engines/table-engines/mergetree-family/replacingmergetree) admite deduplicación en tiempo de consulta con `FINAL`; la corrección no debe depender de que las fusiones en segundo plano ya hayan ocurrido. La [referencia de update](/es/reference/statements/update) describe otro mecanismo de actualización y sus limitaciones. No conviene dar por supuesto que ninguno de los dos patrones ofrezca garantías transaccionales al estilo de PostgreSQL.

<h3 id="transactional-job-state">
  Estado transaccional del job
</h3>

Evalúe ClickHouse Managed Postgres cuando la tabla de ejecuciones también funcione como cola de trabajo transaccional o sistema de registro: por ejemplo, cuando un worker deba reclamar un job de forma atómica mientras otros workers compiten por él, o cuando varios registros de la aplicación deban modificarse de forma conjunta con restricciones aplicadas.

Postgres también puede atender consultas de generación de informes. Añada un servicio analítico cuando los requisitos representativos de rendimiento de consultas, concurrencia o aislamiento lo justifiquen, en lugar de dar por sentado que toda aplicación de informes necesita dos bases de datos.

<h3 id="transactions-and-analytics">
  Transacciones y analítica en conjunto
</h3>

Cuando ambas cargas de trabajo justifican servicios separados, mantenga el estado transaccional en Postgres y replique las tablas necesarias en ClickHouse mediante [ClickPipes](/es/products/managed-postgres/sync-to-clickhouse/clickpipes) o [WalShadow](/es/products/managed-postgres/sync-to-clickhouse/walshadow). Tenga en cuenta el retraso de replicación y siga utilizando la fuente transaccional para las decisiones que requieran el estado actual de la aplicación. La replicación no hace que una escritura en Postgres y una lectura en ClickHouse formen parte de una misma transacción.

La [extensión pg\_clickhouse](/es/products/managed-postgres/extensions/pg_clickhouse/introduction) puede proporcionar acceso a ClickHouse a través de Postgres. Un punto de entrada de consultas compartido no convierte ambos servicios en un único motor de base de datos ni elimina la necesidad de tener en cuenta la actualidad de los datos.

<h2 id="check-fit">
  Comprueba la idoneidad antes del aprovisionamiento
</h2>

Escribe un conjunto reducido de consultas representativas y pruébalas con volúmenes de datos realistas. Incluye tanto lookups puntuales como agregaciones que abarquen todo el histórico, la carga concurrente prevista y los casos de corrección que resulten relevantes para tu aplicación. Documenta el esquema, la forma de las consultas, el tamaño del hardware o del servicio y el comportamiento de ingestión junto con cualquier resultado de benchmark.

En un despliegue gestionado, comprueba además:

* Los requisitos de región, red, control de acceso y recuperación.
* El tiempo activo previsto, los datos almacenados, las copias de seguridad y los cargos por transferencia en la [guía de facturación de ClickHouse Cloud](/es/products/cloud/reference/billing/billing-overview) o la [guía de precios de Managed Postgres](/es/products/managed-postgres/pricing).
* Si una carga de trabajo analítica intermitente puede tolerar el retardo de conexión asociado al [reposo automático](/es/products/cloud/features/autoscaling/idling).
* La responsabilidad del equipo sobre el diseño del esquema, los reintentos de la aplicación, el ajuste de consultas y el control de costes, incluso cuando el servicio gestiona la infraestructura.

Para los servicios de ClickHouse o Postgres en ClickHouse Cloud, usa la [ClickHouse CLI](/es/products/cloud/features/cli) para crear y administrar recursos desde un terminal. Para Managed ClickStack y chDB, sigue las guías de producto enlazadas en el mapa de cargas de trabajo.
