
Cloudflare behebt Query-Planning-Bottleneck in ClickHouse
Cloudflare nutzt ClickHouse als zentralen Datenspeicher für seine Billing-Pipeline, die aufgrund des globalen Traffics des Unternehmens unter hoher Abfragelast steht. Bei der Analyse einer Verlangsamung stellte das Team fest, dass der Engpass nicht im Datentransfer oder der Aggregation lag, sondern im Query-Planning-Stage von ClickHouse selbst. Konkret wurde ein exklusiver Lock (Exclusive Lock) identifiziert, der bei jeder Abfrage das Zugreifen auf die Parts-Liste serialisierte – also alle parallel eingehenden Queries in der Planungsphase blockierte. Zusätzlich erstellte ClickHouse pro Abfrage eine vollständige Kopie der Parts-Liste, was bei großen Tabellen mit vielen Parts zu erheblichem Speicher- und CPU-Overhead führte. Der von Cloudflare entwickelte Patch adressiert alle drei Probleme: Der Exclusive Lock wird durch einen Shared Lock ersetzt, der parallelen Lesezugriff auf die Parts-Liste erlaubt; die pro-Query-Kopie der Parts-Liste entfällt; und das Part-Filtering wurde verbessert, sodass irrelevante Parts früher aus der Betrachtung ausgeschlossen werden. Die Analyse und der Patch wurden von Cloudflare öffentlich dokumentiert, was anderen Teams mit ähnlichen hochfrequenten ClickHouse-Deployments direkt nützen kann. Autor des InfoQ-Berichts ist Renato Losio.
- Engpass lag im Query-Planning-Stage, nicht in Aggregation oder I/O – ein unerwarteter Befund für ein Datenpipeline-Problem.
- Der Exclusive Lock serialisierte parallele Abfragen vollständig in der Planungsphase, sodass selbst kurze Queries auf den Lock warten mussten.
- Pro Query wurde eine vollständige Kopie der Parts-Liste angelegt – bei großen Tabellen ein signifikanter Overhead in Speicher und Verarbeitungszeit.
- Der Patch verbessert das Part-Filtering, sodass nicht relevante Parts bereits vor dem eigentlichen Query-Execution-Plan aussortiert werden.
- Cloudflare hat den Patch intern entwickelt und den Analyseweg öffentlich beschrieben, um der ClickHouse-Community als Referenz zu dienen.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
- LAUNCHgithub.blog2w
GitHub Availability Report: Zwei Vorfälle im September 2026
- LAUNCHvercel.com1w
Vercel zeigt Build-Cache-Größe in Deployment-Übersichten an
- FORSCHUNGarxiv.org3d
Systematischer Review: LLM-Serving in der Cloud – Architektur, Orchestrierung, Inferenz
- LAUNCHinfoq.com2w
Cloudflare Traces in Open Beta: Proxy-Layer als OpenTelemetry Spans

Cloudflare behebt Query-Planning-Bottleneck in ClickHouse
Cloudflare nutzt ClickHouse als zentralen Datenspeicher für seine Billing-Pipeline, die aufgrund des globalen Traffics des Unternehmens unter hoher Abfragelast steht. Bei der Analyse einer Verlangsamung stellte das Team fest, dass der Engpass nicht im Datentransfer oder der Aggregation lag, sondern im Query-Planning-Stage von ClickHouse selbst. Konkret wurde ein exklusiver Lock (Exclusive Lock) identifiziert, der bei jeder Abfrage das Zugreifen auf die Parts-Liste serialisierte – also alle parallel eingehenden Queries in der Planungsphase blockierte. Zusätzlich erstellte ClickHouse pro Abfrage eine vollständige Kopie der Parts-Liste, was bei großen Tabellen mit vielen Parts zu erheblichem Speicher- und CPU-Overhead führte. Der von Cloudflare entwickelte Patch adressiert alle drei Probleme: Der Exclusive Lock wird durch einen Shared Lock ersetzt, der parallelen Lesezugriff auf die Parts-Liste erlaubt; die pro-Query-Kopie der Parts-Liste entfällt; und das Part-Filtering wurde verbessert, sodass irrelevante Parts früher aus der Betrachtung ausgeschlossen werden. Die Analyse und der Patch wurden von Cloudflare öffentlich dokumentiert, was anderen Teams mit ähnlichen hochfrequenten ClickHouse-Deployments direkt nützen kann. Autor des InfoQ-Berichts ist Renato Losio.
- Engpass lag im Query-Planning-Stage, nicht in Aggregation oder I/O – ein unerwarteter Befund für ein Datenpipeline-Problem.
- Der Exclusive Lock serialisierte parallele Abfragen vollständig in der Planungsphase, sodass selbst kurze Queries auf den Lock warten mussten.
- Pro Query wurde eine vollständige Kopie der Parts-Liste angelegt – bei großen Tabellen ein signifikanter Overhead in Speicher und Verarbeitungszeit.
- Der Patch verbessert das Part-Filtering, sodass nicht relevante Parts bereits vor dem eigentlichen Query-Execution-Plan aussortiert werden.
- Cloudflare hat den Patch intern entwickelt und den Analyseweg öffentlich beschrieben, um der ClickHouse-Community als Referenz zu dienen.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
- LAUNCHgithub.blog2w
GitHub Availability Report: Zwei Vorfälle im September 2026
- LAUNCHvercel.com1w
Vercel zeigt Build-Cache-Größe in Deployment-Übersichten an
- FORSCHUNGarxiv.org3d
Systematischer Review: LLM-Serving in der Cloud – Architektur, Orchestrierung, Inferenz
- LAUNCHinfoq.com2w
Cloudflare Traces in Open Beta: Proxy-Layer als OpenTelemetry Spans