ClickhouseClickHouseProblem & solution
How Eisan made POS analytics faster, cheaper, and more reliable with ClickHouse Cloud
Summary
Eisan System Development moved a retail analytics workload from a QlikView-based platform to ClickHouse Cloud after rising ID-POS data volumes caused slower processing, failed analyses, and increasing licensing and server costs. Client records from supermarkets and drugstores support basket analysis, cross analysis, and real-time personalization, with some datasets nearing 200 million records annually. The team compared open-source options including PostgreSQL and YugabyteDB, then tested ClickHouse configurations, including a 30-core, 120-GB setup, while accounting for cache memory usage through load testing. In comparison, ClickHouse ran on slightly lower-spec hardware under high-load conditions without observed performance deterioration, and Eisan reports no cases so far where it failed to return a result; the team is now targeting 100 billion records and exploring off-hours processing and scheduled scaling.
Context
A client’s QlikView-based analytics system was strained by growing ID-POS data volumes and rising expectations for real-time insight. Some processes took minutes, analysis results sometimes failed to return, and memory consumption, licensing, and server costs increased as more clients and deployments were added.
Approach / What changed
Eisan evaluated PostgreSQL, YugabyteDB, and other alternatives before adopting ClickHouse Cloud. The team tested CPU and memory configurations, including 30 cores with 120 GB of RAM, investigated cache-related memory usage with the ClickHouse Japan team, and continues load testing while considering off-hours processing, autoscaling, and scheduled scaling.
Takeaways
ClickHouse maintained stable performance under high-load settings on a server with slightly lower specifications than typical setups, while QlikView increasingly failed to return some analysis results.
Eisan’s configuration testing showed that apparently low memory utilization included memory used for caching; accounting for cache usage made the 30-core, 120-GB setup appear more balanced.
The team aims to support 100 billion records and is exploring off-hours workloads, autoscaling, and possibly shutting down operations during low-use periods such as Sundays.
Source and freshness
- Source
- clickhouse.com
- Published
- Added to Yomu
- Last updated
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.