ChistaDATA Server for ClickHouse: production ClickHouse, engineered and operated around the clock

Public evidence

The scale open-source ClickHouse is proven at

We do not publish invented benchmarks. The strongest argument for running ClickHouse seriously is what operators have already published about it. Cloudflare’s engineering team documented its HTTP analytics pipeline on ClickHouse in 2018, and the numbers still set the bar for what a well-engineered cluster can absorb.

The storage outcome is the part most teams underestimate. Each request arrived as a 1,630-byte message, compressed to 360 bytes with zstd, and settled into ClickHouse at 36.74 bytes per row. That is roughly 44 times smaller than raw, across more than 100 columns per request and a 365-day retention requirement.

Those results come from sort-key design, codec choice, partitioning and merge behaviour, which is exactly the layer ChistaDATA Server standardises. Your own numbers will differ with your data, and we measure them on your workload before we promise anything.

Source: Cloudflare engineering blog, HTTP Analytics for 6M requests per second using ClickHouse. ClickHouse project statistics: ClickHouse on GitHub.

Measurement first

Performance engineering on ChistaDATA Server, measured in system tables

Every recommendation we make starts from telemetry the server already records. The first query we run on a new estate is a p95 and p99 latency profile by normalized query shape, because the slowest 1% of queries is where dashboards time out and where hardware budgets go.

-- p95 / p99 latency and read volume by query shape, last 24 hours
SELECT
    normalized_query_hash,
    any(query)                                   AS sample_query,
    count()                                      AS executions,
    quantile(0.95)(query_duration_ms)            AS p95_ms,
    quantile(0.99)(query_duration_ms)            AS p99_ms,
    formatReadableSize(sum(read_bytes))          AS total_read,
    formatReadableSize(max(memory_usage))        AS peak_memory
FROM system.query_log
WHERE type = 'QueryFinish'
  AND event_date >= today() - 1
  AND event_time >= now() - INTERVAL 24 HOUR
GROUP BY normalized_query_hash
ORDER BY p99_ms DESC
LIMIT 20;

The second check is part health. Too many active parts per partition is the most common root cause of TOO_MANY_PARTS errors, insert throttling and merge backlogs. ClickHouse starts delaying inserts at the parts_to_delay_insert threshold and rejects them at parts_to_throw_insert, so we alert well before either.

-- Active parts per partition, compared with the table's own thresholds
SELECT
    database,
    table,
    partition,
    count()                                      AS active_parts,
    formatReadableSize(sum(bytes_on_disk))       AS on_disk,
    round(sum(data_uncompressed_bytes) / sum(data_compressed_bytes), 1) AS compression_ratio
FROM system.parts
WHERE active
GROUP BY database, table, partition
ORDER BY active_parts DESC
LIMIT 20;

Reliability engineering

High availability and disaster recovery with ChistaDATA Server

A replica you have never failed over to is a hope, not a plan. ChistaDATA Server treats availability as something you measure: replication delay, Keeper quorum health, backup age and the time a restore actually takes.

ClickHouse Keeper uses Raft, so quorum arithmetic is fixed: a 3-voter ensemble tolerates one failure and a 5-voter ensemble tolerates two. We place voters across failure domains, keep Keeper off the busiest data nodes, and never run an even number of voters.

For regional DR we combine asynchronous replicas in a second region with checksummed full and incremental backups in object storage, and we run restore and failover drills every quarter with the customer’s team watching.

Every table is created with an explicit engine definition. We never rely on defaults in customer estates, because defaults change between releases.

CREATE TABLE analytics.events ON CLUSTER 'prod_cluster'
(
    event_date   Date,
    event_time   DateTime64(3, 'UTC'),
    tenant_id    UInt32,
    event_type   LowCardinality(String),
    user_id      UInt64,
    payload      String CODEC(ZSTD(3))
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/analytics/events', '{replica}')
PARTITION BY toYYYYMM(event_date)
ORDER BY (tenant_id, event_type, event_time)
TTL event_date + INTERVAL 90 DAY TO VOLUME 'cold'
SETTINGS index_granularity = 8192, storage_policy = 'hot_cold';

Vendor-neutral view

ChistaDATA Server vs DIY ClickHouse vs a managed cloud service

We are vendor-neutral by principle, and we will tell you when a different model fits better. A fully managed ClickHouse service can be the right answer for small teams with no residency constraints. ChistaDATA Server is built for estates that need control of the infrastructure and a team accountable for the outcome.

Engagement model

How a ChistaDATA Server engagement runs

Moving from Redshift, Snowflake, BigQuery, Druid, Pinot, Vertica or Elasticsearch? Our ClickHouse migration practice plans schema translation, dual-running and cutover with a rollback path at every step.

FAQ

ChistaDATA Server for ClickHouse: frequently asked questions