Analytics Heavy (OLAP)
read heavySummary
Complex analytical queries over large historical datasets, typically scanning gigabytes per query for aggregations, joins, and window functions. Query throughput is low but each query is CPU- and I/O-intensive. Freshness requirements are minutes to hours, not milliseconds.
Example Systems
- ·Business intelligence dashboard (Looker, Metabase)
- ·Data warehouse reporting layer
- ·Cohort analysis platform
- ·Revenue analytics service
- ·Ad attribution pipeline
Characteristics
Capacity
Access Patterns
Recommended Patterns
Patterns to Avoid
Basis
OLAP characteristics are well-documented through Redshift, BigQuery, and Snowflake operational guides
Related Architecture Knowledge
Outbound: this entity affects
Analytics-heavy workloads pre-compute expensive aggregations and joins into materialized views, reducing repeated full-scan query cost from minutes per query to milliseconds per lookup.
Tradeoffs
- ·Materialized views add write overhead (refresh cost) and storage overhead (duplicate data)
- ·Stale materialized views silently serve stale data: requires monitoring of last_refresh timestamp
- ·Complex views with many dependencies make refresh ordering complex
Analytics-heavy workloads that require aggregate queries across all shards are particularly vulnerable to cross-shard query degradation as shard count grows.
Full relationship →Inbound: affects this entity
ClickHouse's columnar storage engine, vectorized query execution, and MergeTree family of table engines are specifically designed for analytics-heavy workloads: high-throughput aggregations over billions of rows with sub-second query latency.
Tradeoffs
- ·ClickHouse has limited transaction support: ACID transactions are not a design goal
- ·Point lookups (SELECT * FROM t WHERE id = X) are slower than PostgreSQL: not an OLTP system
- ·INSERT performance is maximized with large batches (1000+ rows): small frequent inserts cause MergeTree pressure
Used In Architecture Scenarios
Analytics Pipeline
An OLAP-oriented analytics architecture that ingests operational changes from PostgreSQL via WAL-based CDC into Kafka, then routes them to a columnar analytics store (ClickHouse or Snowflake) for product analytics, business intelligence, and operational reporting. The CQRS separation ensures analytical queries never degrade transactional write performance, and materialized views provide pre-aggregated query acceleration for the most expensive analytical patterns.
AI / RAG Application
A low-latency feature serving platform for ML model inference, providing both batch (offline) and real-time (online) feature access with strict training-serving consistency. Redis serves the hot feature cache with p99 latency targets below 5ms for online inference requests; PostgreSQL provides point-in-time feature lookups for offline training jobs with temporal consistency guarantees; Cassandra stores high-cardinality feature entities at write scale beyond PostgreSQL's single-primary ceiling; Kafka streams feature computation events from online feature pipelines to update the cache; Qdrant stores vector features for embedding-based model inputs and similarity lookups; ClickHouse serves feature analytics and drift monitoring across training dataset populations. Feature versioning is first-class: every feature value is tagged with a pipeline_version and computed_at timestamp to support model reproducibility and training-serving skew diagnosis.
Analytics Pipeline
A metrics, logs, and traces ingestion and query platform built to absorb the telemetry output of a production system fleet: including the telemetry volume spikes that accompany the incidents the platform is meant to detect. ClickHouse stores metrics data with automatic time-based rollup via continuous materialized views; TimescaleDB provides complementary time-series storage for high-cardinality alert evaluation; Kafka buffers the ingestion stream against downstream write pressure, decoupling ingest acceptance rate from storage write throughput; Elasticsearch serves log full-text search and structured field filtering; Redis caches dashboard query results and active alert state for sub-100ms alert evaluation latency. The alert engine evaluates threshold and anomaly rules against pre-computed materialized views, not raw data, to bound alert evaluation cost independent of ingestion volume.