隔离读写工作负载

​

为何要将读与写隔离

• 写入不再拖慢读取。 持续的 OpenTelemetry 摄取——既包括插入本身，也包括随之而来的后台合并——会与仪表板和搜索查询争抢 CPU 和内存。摄取进行期间，读取延迟可能明显变差，摄取停止后才会恢复。
• 读取不再干扰写入。 这种争抢是双向的：一次繁重的临时查询或一次开销高昂的仪表板渲染可能耗尽服务的内存，直接导致插入失败，而不只是变慢。
• 只读计算资源完全专用于查询。 只读服务除系统表外不执行任何后台合并。它们还能立即进入空闲状态，而读写服务则可能因合并而一直保持唤醒。
• 两侧各自独立进行容量规划。 容量规划模型会分别估算摄取所需计算资源和查询所需计算资源，而仓库允许你将两者各自部署为独立的服务。一旦超过该模型 1 QPS 的基线，查询计算资源便占据主导——其 5 QPS 下的实例演算得出摄取需要 58 个 vCPU，而查询需要 290 个——因此一个较小的写入服务即可支撑一个大得多的读取服务。
• 空闲与自动扩缩容按服务分别配置。 每个服务都有各自的副本数、自动扩缩容和自动空闲设置，因此写入服务可以为持续摄取保持始终在线，而读取服务可在非工作时间进入空闲状态。
• 存储不会重复。 同一仓库中的服务共享相同的对象存储目录和相同的表，并且存储只计费一次。
• 可按端点限制访问。 IP 访问列表按服务生效，因此写入端点可以只允许你的 collector 访问，而读取端点只允许你的 ClickStack 部署访问。请参阅我们关于网络访问控制的指南。

​

架构

• warehouse 中的第一个 service 始终为读写类型，且 service 的类型在创建时即已固定——若要在只读与读写之间切换，需在该 warehouse 中新建一个 service。
• 同一 warehouse 中的所有 service 共享相同的云提供商、区域、ClickHouse 版本和 Keeper，并沿用 primary service 的 upgrade schedule。
• 摄取只使用一个读写 service。合并任务会分配到共享同一存储的所有读写 service 上，因此某个 service 上的插入所触发的合并可能由另一个 service 执行。如果那个 service 同时还承担着繁重的查询，这些查询就会与合并争抢它所在 service 的 CPU 和内存——导致第一个 service 的插入所对应的合并变慢，进而拖累插入性能。请把查询工作负载放在只读 service 上，仅在需要将合并与摄取分离时才增加第二个读写 service。

​

搭建隔离部署

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;

​

将合并与摄取分离

• 不要依赖任一读写服务的自动空闲。 禁用了合并的服务仍会处理仓库中其他服务插入数据所产生的 part 下载与移除事件,而未合并 parts 数量过多本身也会阻止进入空闲状态。请按两个读写服务持续保持唤醒来规划。
• 不要让查询落到任何一个读写服务上。 在读写服务上执行繁重的 SELECT 查询会与合并工作争抢 CPU 和内存,而这正是该拓扑要规避的故障模式。请按上文所述,将 ClickStack 指向只读服务。
• 如果存在变更,它们会在执行它们的服务上被跟踪。 变更在可观测性场景中很少见——ClickStack 的 schema 设置了 ttl_only_drop_parts = 1,因此常规的数据保留会在 TTL 合并期间整体删除已过期的 parts,而不是通过变更逐行删除数据。如果你确实向摄取服务提交了会产生变更的 ALTER,它将由合并服务执行,其进度也会出现在合并服务的 system.mutations 中,而不是摄取服务上。

​

管理与 DDL

• 建表 —— 由 ClickStack collector 在首次摄取时自动完成
• 修改生存时间 (TTL) 以调整数据保留策略
• 创建 materialized views 以加速查询
• 添加跳过索引、projections 及其他性能优化

CREATE DATABASE otel
SETTINGS distributed_ddl_task_timeout=0

​

隔离智能体工作负载

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

​

告警

​

隔离告警评估

• 公共告警以及与之配套的仪表盘只存在于告警 service 上，在查询 service 上工作的用户看不到它们。但无论哪种方式，通知都会发送到相同的目标端，因此用户失去的只是对定义的可见性，而非告警能力本身。
• 告警 service 上的 source 是独立的对象。使用默认 OpenTelemetry schema 的 source 会被自动检测，但自定义 source 也必须在这里配置一遍，告警才能引用它们。

​

进一步考量