Trip.com's 2012 Elasticsearch logging platform hit a wall at 4PB — request rejections, out-of-memory queries, and daily hot-to-cold migrations that degraded the whole cluster. ClickHouse took it from there to 40PB+.

Before 2012, trip.com had no unified logging platform — every team ran its own, which meant duplicated engineering effort, inconsistent data governance, and no company-wide standard. In 2012 they launched a centralized platform to fix exactly that, built on Elasticsearch, with Kibana on top for visualization and Kafka carrying logs in from producers.

It worked well enough to become the standard — until the data volume it was built for stopped being the data volume it actually had.

Trip.com’s own comparison, on the same sample of data: storage space savings exceeded 50%, enough that the existing Elasticsearch-era servers could support a 4x increase in data volume once moved to ClickHouse. Query speed came in 4 to 30 times faster than Elasticsearch, with a P90 under 300ms and a P99 under 1.5 seconds.

Since finishing that migration in 2022, the platform kept growing — from 4PB to 20PB, and on toward what they now describe as a 40PB+ deployment.

Crossing over meant redesigning storage from scratch: ReplicatedMergeTree tables partitioned by day, ordered by log level and timestamp for the queries that actually get run, a tokenbf_v1 Bloom filter for fuzzy and term matching, and ZSTD compression that alone saved over 40% of storage cost. Because Kibana was originally built only for Elasticsearch, trip.com had to build custom ClickHouse-aware panel types for it — histogram, hits, percentiles, and more — so existing dashboards wouldn’t need to be rebuilt from zero.

Growth past the original migration didn’t stay free. By 20-30PB, a single ClickHouse cluster became hard to manage: without ClickHouse-Keeper or SharedMergeTree available yet at that point, Zookeeper became the bottleneck, causing DDL timeout exceptions. The fix wasn’t a bigger single cluster — it was multiple clusters, deployed on Kubernetes with StatefulSets and anti-affinity rules, which cut the delivery time for a new cluster from 2 days to 5 minutes. Moving data between clusters when one filled up required a manual dual-write-then-delete process that trip.com itself calls “cumbersome and slow” — a real trade-off they accepted rather than solved.

A migration that fixes the bottleneck you have doesn’t retire the concept of a bottleneck — at 40PB+, the new one was Zookeeper metadata, not query speed, and the fix was organizational, more and smaller clusters, as much as it was a database swap.