{"type":"rich","version":"1.0","provider_name":"Transistor","provider_url":"https://transistor.fm","author_name":"Programming Tech Brief By HackerNoon","title":"Block decomposition: how ClickHouse, Prometheus, and InfluxDB rediscovered the same fundamental algo","html":"<iframe width=\"100%\" height=\"180\" frameborder=\"no\" scrolling=\"no\" seamless src=\"https://share.transistor.fm/e/67fd7bad\"></iframe>","width":"100%","height":180,"duration":1130,"description":"\n        This story was originally published on HackerNoon at: https://hackernoon.com/block-decomposition-how-clickhouse-prometheus-and-influxdb-rediscovered-the-same-fundamental-algo.\nClickHouse, Prometheus, and InfluxDB independently landed on the same idea: sqrt-decomposition. Here's where the model holds — and where it breaks.\nCheck more stories related to programming at: https://hackernoon.com/c/programming.\n            You can also check exclusive content about #software-engineering, #software-architecture, #data-structures, #decomposition-patterns, #time-series-database, #clickhouse, #prometheus, #hackernoon-top-story,  and more.\nThis story was written by: @ivan-fekete. Learn more about this writer by checking @ivan-fekete's about page,\n            and for more stories, please visit hackernoon.com.\nClickHouse, Prometheus, and InfluxDB were built by different teams, in different languages, for partially different workloads — yet all three read data the same way: split the timeline into sealed blocks, keep a small summary next to each one, and answer a range query by skipping whole blocks and scanning only the partial ones at the edges. That's square-root decomposition, the structure competitive programmers reach for when trees don't fit the query pattern.\nThe model isn't followed literally. Nobody picks B = sqrt(N), because N grows forever and recent data must stay cheap to reach; block sizes are fixed instead (8192 rows, ~120 samples, a 2-hour window) and driven by the compression algorithm rather than by asymptotics. Decomposition is also two-dimensional in practice: time is one axis, label filtering is another, handled by a separate inverted index, and real query cost lives at their intersection. And updates are appends, not random writes — the summary cost shows up as background compaction.\nThe practical payoff: block size is the tuning knob (pruning accuracy and index size vs. compression and scan throughput), single-row reads are structurally slow...","thumbnail_url":"https://img.transistorcdn.com/KhCapPSRkLGL2Xw8888yuChkNRWthaKapLYTvNdu4W4/rs:fill:0:0:1/w:400/h:400/q:60/mb:500000/aHR0cHM6Ly9pbWct/dXBsb2FkLXByb2R1/Y3Rpb24udHJhbnNp/c3Rvci5mbS9zaG93/LzQxMTY2LzE2ODM1/ODIzMzAtYXJ0d29y/ay5qcGc.webp","thumbnail_width":300,"thumbnail_height":300}