Aislar los workloads de lectura y escritura

​

Por qué aislar las lecturas de las escrituras

• Las escrituras dejan de degradar las lecturas. La ingestión continua de OpenTelemetry —los inserts en sí, más las fusiones en segundo plano que los siguen— compite con las consultas de dashboards y búsquedas por CPU y memoria. La latencia de lectura puede degradarse de forma notable mientras la ingestión está en curso, y se recupera cuando esta se detiene.
• Las lecturas dejan de interferir con las escrituras. La contención se produce en ambos sentidos: una consulta ad-hoc pesada o la renderización costosa de un dashboard pueden agotar la memoria del service y hacer que los inserts fallen directamente, no solo que se ralenticen.
• El compute de solo lectura se dedica por completo a las consultas. Los read-only services no realizan fusiones en segundo plano fuera de las system tables. Además, pasan a estado idle sin demora, a diferencia de los read-write services, a los que las fusiones pueden mantener activos.
• Cada lado se dimensiona por separado. El sizing model estima por separado el compute de ingestión y el de consultas, y un warehouse te permite provisionar cada uno como un service independiente. Por encima del baseline de 1 QPS del modelo, el compute de consultas predomina —su ejemplo práctico con 5 QPS llega a 58 vCPU para la ingestión frente a 290 para las consultas—, por lo que un service de escritura pequeño puede alimentar a un service de lectura mucho mayor.
• El idling y el autoscaling se configuran por service. Cada service tiene su propio número de réplicas y sus propios ajustes de autoscaling y auto-idling, de modo que el service de escritura puede permanecer siempre activo para la ingestión continua mientras el service de lectura pasa a idle fuera del horario laboral.
• El almacenamiento no se duplica. Los services de un warehouse comparten la misma carpeta de object storage y las mismas tablas, y el almacenamiento se factura una sola vez.
• El acceso puede restringirse por endpoint. Las IP access lists se aplican por service, por lo que el endpoint de escritura puede ser accesible únicamente desde tus collectors y el endpoint de lectura únicamente desde tu implementación de ClickStack. Consulta nuestra guía sobre Control de acceso de red.

​

Arquitectura

• El primer servicio de un warehouse siempre es read-write, y el tipo de servicio queda fijado en el momento de su creación: para cambiar entre read-only y read-write, crea un nuevo servicio en el warehouse.
• Todos los servicios de un warehouse comparten el mismo proveedor de nube, región, versión de ClickHouse y Keeper, así como la programación de upgrade del servicio primario.
• Usa un solo servicio read-write para la ingestión. Las fusiones se reparten entre todos los servicios read-write que comparten el almacenamiento, de modo que la fusión correspondiente a un insert en un servicio puede acabar ejecutándose en otro. Si ese otro servicio además atiende consultas pesadas, esas consultas competirán con la fusión por CPU y memoria en el servicio que la ejecuta, lo que ralentiza las fusiones de los inserts del primer servicio y, con ellas, el rendimiento de inserción. Mantén los workloads de consulta en el servicio read-only y añade un segundo servicio read-write solo si necesitas separar las fusiones de la ingestión.

​

Configurar un despliegue aislado

CREATE DATABASE otel;
CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY '<strong-password>';
GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest;

CLICKHOUSE_ENDPOINT=https://<read-write-service>.clickhouse.cloud:8443
CLICKHOUSE_USER=hyperdx_ingest
CLICKHOUSE_PASSWORD=<strong-password>
HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel

SELECT 
    user, 
    query_kind, 
    http_user_agent,
    count()
FROM clusterAllReplicas('default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10) 
  AND type = 'QueryFinish'
  AND is_initial_query = 1
GROUP BY ALL
ORDER BY count() DESC;

SELECT 
    hostName() AS host, 
    query_kind, 
    count()
FROM clusterAllReplicas('all_groups.default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10) 
  AND type = 'QueryFinish'
  AND is_initial_query = 1
GROUP BY ALL;

​

Separar las fusiones de la ingestión

• No dependas del auto-idling en ninguno de los dos servicios de lectura y escritura. Un servicio con las fusiones deshabilitadas sigue procesando los eventos de descarga y eliminación de partes que generan las inserciones en otros puntos del warehouse, y un número elevado de partes sin fusionar puede bloquear el idling por sí solo. Prevé que ambos servicios de lectura y escritura estén continuamente activos.
• Mantén las consultas fuera de ambos servicios de lectura y escritura. Las consultas SELECT pesadas en un servicio de lectura y escritura compiten por CPU y memoria con el trabajo de fusión, que es precisamente el modo de fallo que esta topología pretende evitar. Apunta ClickStack al servicio de solo lectura tal como se describe más arriba.
• Las mutaciones, cuando las haya, se registran en el servicio que las ejecuta. Las mutaciones son poco frecuentes en observabilidad: el esquema de ClickStack establece ttl_only_drop_parts = 1, por lo que la retención ordinaria elimina partes expiradas completas durante las fusiones de TTL en lugar de mutar filas para borrarlas. Si envías al servicio de ingestión un ALTER que produce una mutación, la ejecuta el servicio de fusión, y su progreso aparece allí en system.mutations y no en el servicio de ingestión.

​

Administración y DDL

• Creación de tablas: la realiza automáticamente el collector de ClickStack en la primera ingestión
• Modificar TTL para cambiar la retención
• Crear vistas materializadas para acelerar las consultas
• Añadir skip indexes, projections y otras optimizaciones de rendimiento

CREATE DATABASE otel
SETTINGS distributed_ddl_task_timeout=0

​

Aislamiento de cargas de trabajo agénticas

claude mcp add --transport http clickstack https://mcp.clickhouse.cloud/clickstack \
  --header "x-service-id: <read-only-agent-service-id>"

​

Alertas

​

Aislar la evaluación de alertas

• Las alertas comunes, y cualquier dashboard asociado a ellas, existen únicamente en el servicio de alertas y no son visibles para los usuarios que trabajan en el servicio de consulta. En ambos casos, las notificaciones se entregan a los mismos destinos, por lo que lo que los usuarios pierden es la visibilidad de las definiciones, no las alertas en sí.
• Las sources del servicio de alertas son objetos independientes. Las que usan el esquema predeterminado de OpenTelemetry se detectan automáticamente, pero las sources personalizadas también deben configurarse allí antes de que una alerta pueda hacer referencia a ellas.

​

Consideraciones adicionales