Tag: clickhouse
How to turn a sharded Distributed + MergeTree table into a single ReplicatedMergeTree table with a full copy on every node: freezing writes, creating the table with a shard-free ZooKeeper path, copying with INSERT ... SELECT, verifying with checksums, and cutting over safely. Rehearsed step by step on dummy data.
A side-by-side look at how ClickHouse and StarRocks use Bloom filters: granules vs pages, tunable vs automatic indexes, text search, join runtime filters, and how to verify each. Plus a decision guide for when to use what.
How ClickHouse uses Bloom filter skip indexes to avoid reading data, how to choose between bloom_filter, tokenbf_v1 and ngrambf_v1, how to size them, and how to tell whether they actually work.
A plain-language tour of StarRocks' storage hierarchy, from catalogs, partitions and tablets down to rowsets, segments and data pages, and how zone maps, bitmap indexes and bloom filters let queries skip most of the data without ever reading it.
After upgrading to ClickHouse 26.2+, re-inserting identical data into Replicated tables can be silently dropped even though the insert reports success. Here's exactly why it happens and the right way to fix it.
When a disk stops responding, the CPU doesn't go idle — it goes into iowait, and many tools (SNMP included) roll that into a single "CPU load" number. So a storage failure shows up as a CPU alarm. This is how one such alert on a production ClickHouse node led down through iowait and a hung txg_sync to the real cause - a single EBS volume, no redundancy, that briefly lost access.
A real production debugging story — how a ReplacingMergeTree table with no version column lets the wrong row quietly win, and why "just delete the table" would have hidden the real bug.
A practical guide to continuously replicating ClickHouse data off-box using ZFS snapshots and zrepl — why it works, how to set it up, how to restore, and the consistency caveats nobody mentions.
A practical guide to load balancing ClickHouse. When HAProxy wins, when chproxy wins, minimal setup for both, and the key parameters that actually matter.
The whole thing is a single Python file with no dependencies — just the standard library. No clickhouse-driver, no requests, no pip install. It talks to ClickHouse over the HTTP interface (port 8123), so you can drop it on any box that can reach the server and run it.
A branch is a full, writable, isolated copy of a production table — created in seconds, without duplicating the data.
Auditing ClickHouse ! That's the layer BlancoByte ClickHouse Console is built around. Here's what it actually looks like.
ClickHouse exposes all of that — through dozens of system tables. It just doesn't give you a single place to actually see it.That gap is exactly what BlancoByte ClickHouse Console was built to close.
EXPLAIN is the cheapest form of observability ClickHouse offers. It runs in milliseconds, it doesn't touch the data, and it can save you from queries that would otherwise have run for hours.
v4 is the rebuild. Multi-user, role-based, audited, multi-cluster, with a hardened deployment, a credential vault, LDAP/AD authentication, SIEM forwarding, and native ClickHouse backup with scheduling. Almost every panel from v1 has been touched. Many are new.
The feedback pointed in a clear direction: teams wanted more control over what gets replicated, better pipeline management, and the ability to connect their own infrastructure. v1.1 delivers all of that.
BlancoByte CDC Connector is built on open-source technologies that have been battle-tested at scale:
Scripts for backups, a Python profiler for slow queries, a branching utility for safe testing.
The tool reads the ClickHouse server log file line-by-line, extracts every executed query along with its execution time, rows read, bytes read, and peak memory usage, then groups structurally identical queries together and ranks them by the metric you care about most.
This is the most important concept to understand before using the tool. There are three types of backups and they behave very differently.
In modern software development, handling data in a reliable and scalable way is essential for building stable applications. As systems grow more complex, teams need safer ways to test changes and experiment with database structures without risking production environments. One technique that has beco
The FREEZE command is an ALTER TABLE operation that creates a local backup of a table or a specific partition.
What if you could run ClickHouse SQL queries without setting up a server or managing storage? That’s exactly what clickhouse-local is for.
The good news? ClickHouse provides a Kafka table engine that lets you subscribe directly to Kafka topics and pipe messages into your database efficiently. By combining Kafka with materialized views in ClickHouse, you can build a reliable ingestion pipeline that continuously transforms and stores mes
Materialized views aren’t just another database feature—they’re a powerful way to precompute and store results, making analytical queries lightning-fast. Let’s dive into what they are, how they differ from regular views, and why they matter.
In today’s data-driven world, speed matters. Whether it’s monitoring user behavior, tracking financial transactions, or analyzing IoT signals, organizations rely on real-time insights to make critical decisions. Traditional row-based databases can struggle to deliver the performance needed at scale,