ClickHouse Real-Time Analytics ve OLAP Veri Ambarı 2026

ClickHouse Nedir ve Neden 2026’da OLAP’ın Standardı Oldu

ClickHouse, sütun tabanlı (columnar) açık kaynak bir OLAP veritabanı yönetim sistemidir; 2016’da Yandex tarafından açık kaynaklı hâle getirildi ve 2024’te ClickHouse Inc. tarafından bağımsız ticari destek aldı. Real-time analytics dünyasında milisaniye altı yanıt süreleri, saniyede yüz milyonlarca satır okuma kapasitesi ve %95’e varan veri sıkıştırma oranlarıyla tanınır. “ClickHouse nedir” sorusunun tek cümlelik cevabı: petabayt ölçekli analitik sorguları kullanıcı bekleme süresi içinde çalıştıran, MergeTree saklama motoru üzerine kurulu, distributed-by-design bir kolon mağazasıdır. Vektörel SIMD yürütme, geç materyalizasyon ve agresif veri budama (data skipping indexes) sayesinde aynı donanımda PostgreSQL’e göre 100-1000x, Snowflake’e göre 3-10x daha düşük maliyetle interaktif analiz sunar.

2025 sonu itibarıyla ClickHouse Inc. raporlarına göre Cloudflare günlük 30 trilyon satır, Uber 500 PB log, eBay 100 PB davranış verisi, Lyft her saniye yaklaşık 5 milyon olay ClickHouse’a yazıyor. GitHub yıldız sayısı 38 binin üzerine çıkarak Druid (~13 bin) ve Pinot (~5 bin) gibi rakipleri açık ara geride bıraktı. Stack Overflow 2025 Developer Survey verilerine göre ClickHouse en sevilen veritabanları listesinde Postgres ve Redis’in ardından üçüncü sıraya yerleşti. Bu yazıda ClickHouse mimarisini, MergeTree iç işleyişini, Kafka entegrasyonunu, materialized view stratejilerini, sharding/replication tasarımını, performans benchmark’larını ve gerçek üretim deneyimimde gördüğüm tuzakları satır satır açıyorum.

Sütun Tabanlı Mimari: Neden 100x Daha Hızlı?

Geleneksel satır tabanlı (row-oriented) sistemlerde (PostgreSQL, MySQL) bir satıra ait tüm kolonlar diskte yan yana tutulur. SELECT avg(price) FROM orders WHERE country='TR' sorgusu için motor, gereksiz onlarca kolonu da okumak zorunda kalır. ClickHouse’ta her kolon ayrı bir dosyada (.bin) saklanır; sadece sorguya katılan kolonlar diskten çekilir, I/O hacmi 10-50 kat düşer. Aynı kolondaki değerler benzer dağılımda olduğundan LZ4, ZSTD veya Delta + Gorilla gibi kodlamalarla sıkıştırma oranı 8:1 ile 30:1 arasında gerçekleşir. ClickHouse Inc. resmî dokümantasyonuna göre tipik bir gözlemleme tablosu için ZSTD(3) ile 12-15x sıkıştırma standarttır.

İkinci kazanç vektörel yürütmeden gelir. Sorgu motoru veriyi tek satır halinde değil, 65.536 değerlik bloklar (column blocks) hâlinde işler. CPU SIMD register’larında AVX-512 ile aynı anda 8 double-precision değer işlenebilir; bu da agregasyonlarda 4-8x ek hızlanma demektir. Üçüncü kazanç primary key tabanlı sparse index’tir: her 8192 satırda bir granül (granule) işaretlenir, sorgu sırasında ilgisiz granüller atlanır. Bir Cloudflare örneğinde 100 milyar satırlık tabloda timestamp + customer_id primary key’i ile yalnızca 47 granül okunarak 30 ms’de cevap döndürülmüştür.

Özellik	ClickHouse	PostgreSQL	Snowflake	BigQuery
Depolama modeli	Columnar	Row	Hybrid (micro-partitions)	Columnar (Capacitor)
Tipik sıkıştırma	10-30x (ZSTD)	2-3x (TOAST)	5-10x	10-15x
Sub-second query (1B row)	Evet	Hayır	Warehouse’a göre	On-demand limit
Vektörel yürütme	SIMD AVX-512	Yok	Var (sınırlı)	Var
Açık kaynak	Apache 2.0	PostgreSQL Lic.	Kapalı	Kapalı
Self-hosted maliyet (TB/ay)	~$15-25	~$50-80	$30-50	$20
Concurrency (önerilen)	100-1000	1000+	Otomatik scale	Slot bazlı

Bu karşılaştırmada açıkça görülen tablo: ClickHouse interaktif tek sorgu hızı ve TCO açısından açık ara önde, ancak yüksek eşzamanlı transactional iş yükü için tasarlanmamıştır. BigQuery vs Snowflake karşılaştırmasında değindiğim cloud warehouse seçim kriterleri ClickHouse için de geçerlidir ancak ek olarak self-hosting operasyon yükü hesaplanmalıdır. Vektörel yürütme ve sparse index detaylarını ClickHouse resmî mimari dokümanından doğrulayabilirsiniz.

MergeTree Engine Ailesi: Tablo Türleri ve Kullanım Senaryoları

ClickHouse’un kalbi MergeTree saklama motorudur. Bu motor verileri sıralı parts hâlinde diske yazar, arka planda bu parçaları birleştirir (merge) ve böylece okuma performansını optimum tutar. MergeTree’nin 8 ana varyantı vardır, her biri farklı bir analitik desen için tasarlanmıştır.

• MergeTree: Genel amaçlı temel motor. Time-series, log, event verisi için varsayılan seçim.
• ReplacingMergeTree: Aynı primary key’e sahip duplicate satırları arka planda temizler. Ne zaman seç: upsert davranışı gereken CDC pipeline’larında.
• SummingMergeTree: Sayısal kolonları primary key bazında otomatik toplar. Avantaj: Materialized view ile birleşince pre-aggregation maliyeti sıfırlanır.
• AggregatingMergeTree: AggregateFunction state’leri saklar; quantile, uniq, avg gibi karmaşık agregasyonlar için.
• CollapsingMergeTree / VersionedCollapsingMergeTree: Sign kolonu ile sürümlü kayıt yönetimi. Dezavantaj: Uygulama tarafında sign bookkeeping gerektirir.
• GraphiteMergeTree: Time-series metrik retention politikaları için özel.
• ReplicatedMergeTree: Yukarıdaki tüm motorların ZooKeeper/Keeper destekli kopyalı versiyonu, production’da zorunlu.

Tablo oluştururken üç tasarım kararı toplam performansın %80’ini belirler: ORDER BY tuple’ı (primary key olarak da kullanılır), PARTITION BY expression’ı ve SETTINGS index_granularity. Primary key sorgularda en sık WHERE’e gelen kolonlardan, low-cardinality’den high-cardinality’ye doğru sıralı olmalıdır. Partition tipik olarak toYYYYMM(event_date) şeklinde aylık seçilir; günlük partition 30 günden kısa retention için anlamlıdır, daha agresif partitionlama merge yükünü patlatır.

Senaryo	Önerilen Engine	Primary Key Örneği	Partition
Web event logs	MergeTree	(event_date, user_id, event_type)	toYYYYMM(event_date)
IoT telemetri	MergeTree + TTL	(device_id, timestamp)	toYYYYMMDD(timestamp)
CDC mirror tablo	ReplacingMergeTree	(table_pk)	toYYYYMM(updated_at)
Pre-aggregated metrics	SummingMergeTree	(metric, dim1, dim2, hour)	toYYYYMM(hour)
Funnel/cohort analysis	AggregatingMergeTree	(user_id, cohort_week)	toYYYYMM(cohort_week)
Mutable order state	VersionedCollapsingMergeTree	(order_id)	toYYYYMM(order_date)

TTL (Time To Live) yan klauzu ile hot/warm/cold tier ayrımı yapılabilir: 30 gün lokal SSD, 90 gün object storage, 365 gün arşiv. ClickHouse’un S3-backed disk politikaları sayesinde aynı tablo üzerinde transparent şekilde çalışır; sorgu yazan kullanıcı tier’ı bilmek zorunda değildir.

Real-Time Veri Alımı: Kafka, RabbitMQ, S3 Entegrasyonları

ClickHouse’un öne çıkan özelliklerinden biri, harici streaming kaynaklarına doğrudan engine seviyesinde entegre olmasıdır. Kafka Engine, ClickHouse tablosunu Kafka topic’inin tüketicisi haline getirir; tek başına veri saklamaz, materialized view ile asıl MergeTree tablosuna akış sağlar. Tipik bir pipeline üç katmandan oluşur: Kafka Engine tablo (raw ingestion), materialized view (transformasyon), hedef MergeTree (kalıcı saklama).

1. CREATE TABLE events_kafka ENGINE = Kafka SETTINGS kafka_broker_list='...', kafka_topic_list='events', kafka_format='JSONEachRow', kafka_num_consumers=4;
2. CREATE TABLE events_data (event_date Date, user_id UInt64, event_type LowCardinality(String), props String) ENGINE = MergeTree() ORDER BY (event_date, user_id);
3. CREATE MATERIALIZED VIEW events_mv TO events_data AS SELECT toDate(timestamp) AS event_date, user_id, event_type, props FROM events_kafka;

Bu üçlü desen saniyede 200.000-1.000.000 mesajı tek bir orta seviye node (16 vCPU, 64 GB RAM, NVMe SSD) ile tüketebilir. Cloudflare’in Magic Network Monitoring servisi bu mimariyi 800 node üzerinde ölçeklendirerek saniyede 25 milyon olay işliyor; vaka çalışmasının detayları Cloudflare mühendislik blogunda paylaşılmıştır. Kafka Engine konfigürasyon parametrelerinin tam listesi ClickHouse Kafka entegrasyon dokümanında bulunur.

S3 entegrasyonu için s3() table function veya kalıcı S3 Engine kullanılır. Parquet, ORC, JSONL, CSV gibi formatları doğrudan okur; data lake katmanından batch yükleme için idealdir. Açık tablo formatları için Iceberg ve Delta Lake ile native entegrasyon ClickHouse 24.x sürümünden itibaren stable; ayrı bir ELT katmanı olmadan lakehouse üzerinde sorgu çalıştırılabilir. Iceberg tablo formatının spesifikasyonu Apache Iceberg resmî sayfasında versiyonlu tutulur. RabbitMQ, NATS, Apache Pulsar engine’leri de mevcut ancak production’da en olgun yol Kafka’dır.

Materialized View’lar ve Pre-Aggregation Stratejisi

Materialized view (MV) ClickHouse’da klasik veritabanlarındakinden farklı çalışır: tetikleyici (trigger) gibi, INSERT geldiğinde otomatik tetiklenir ve sonucu hedef tabloya yazar. Bu mimari sayesinde 1 trilyon satırlık ham tablo üzerinde dakikalar süren bir agregasyon, MV ile pre-compute edilmiş haliyle 50 ms’de döner. Üç ana MV stratejisi vardır:

• Roll-up (Summing/Aggregating): Saatlik veya günlük granülerlikte rakamları toplar. Dashboard sorguları için temel taş.
• Projection (built-in alternative): ClickHouse 21.x’ten beri tablo içinde tanımlanan, sorgu planlayıcının otomatik seçtiği alternatif veri kopyaları. Avantaj: Ayrı tablo yönetimi gerektirmez. Dezavantaj: Tüm INSERT’leri yavaşlatır.
• Fan-out denormalization: JOIN’siz okuma için MV ile geniş tablo üretmek. OLAP’ın star schema mantığına alternatif.

AggregatingMergeTree ile birleştiğinde MV son derece güçlüdür. Bir e-ticaret örneğinde günlük 2 milyar event üreten bir tabloda uniqState(user_id) ve quantilesState(0.5, 0.95, 0.99)(response_time) kolonları AggregatingMergeTree MV’sinde tutuluyor; final dashboard sorgusu uniqMerge ve quantilesMerge ile sub-second çalışıyor. Burada kritik nokta: state kolonları HyperLogLog gibi yaklaşık veri yapıları kullandığı için tam doğruluk değil, %0.5-1 hata payı vardır; SLA’nizi buna göre belirleyin.

Agregasyon Tipi	Fonksiyon	State Boyutu	Hata Payı
Unique count	uniqHLL12	~3 KB	~1.6%
Unique count (precise)	uniqExact	Eleman sayısı * boyut	0%
Quantile (approximate)	quantileTDigest	~1-5 KB	~0.5%
Quantile (precise)	quantileExact	Veri boyutu	0%
Top-K	topK(K)	~K * 100 byte	~5%
Sum/Avg/Min/Max	sumState, avgState	8-16 byte	0%

Materialized view zincirlemeyi de destekler: ham tablo → 1 dakikalık MV → saatlik MV → günlük MV. Her seviye bir önceki seviyenin agregasyonunu sürdürür; saatlik dashboard günlük tabloya, ay görünümleri saatlik MV’ye düşer. Bu yaklaşımda toplam disk kullanımı ham verinin %5-15’i kadar olur ancak sorgu performansı 1000x’e kadar artar.

Sharding ve Replication: Distributed Mimari

Production ClickHouse kümeleri Distributed table engine üzerine kuruludur. Distributed tablo fiziksel veri tutmaz; sorguyu shard’lara dağıtır, sonuçları birleştirir. Replication ise ZooKeeper veya ClickHouse Keeper (Raft tabanlı yerleşik koordinatör, 22.x’ten beri stable) ile yapılır. Tipik bir cluster konfigürasyonu 3+3 (3 shard, her shard’da 2 replika) veya 6+6 şeklindedir.

Shard key seçimi kümenin başarısını belirler. Rastgele dağıtım (rand()) yük dengesi sağlar ama JOIN’lerde shuffle gerektirir; user_id gibi bir kolonla deterministik sharding aynı kullanıcının verisini aynı node’a alır, lokal JOIN mümkün olur ancak sıcak nokta riski oluşur. ClickHouse Inc.’in 2025 önerisi: high-cardinality bir hash (cityHash64(user_id)) ile sharding + distributed_aggregation_memory_efficient=1 ayarı, çoğu iş yükü için optimum noktadır.

• Klasik dağıtım: shard = user_id % N — basit, ancak yeniden sharding pahalı.
• Hash-based: cityHash64(user_id) — daha dengeli yük.
• Time-based partitioning + replication: Tüm shard’larda aynı tarih aralığı — geriye dönük analizler için.
• Locality-aware: Multi-region cluster’da bölgesel okuma optimizasyonu.

Keeper’ın ZooKeeper yerine kullanılması 2025’te best practice oldu: aynı binary içinde, daha düşük latency, daha az operasyonel yük. 3-node Keeper quorum’u 50.000 replication operasyonunu saniyede karşılayabilir. Java tabanlı ZooKeeper’ın bellek baskısı ve GC tepe noktalarıyla uğraşmak istemiyorsanız Keeper’a geçin; geri dönüş yapanlardan henüz hayır diyeni duymadım.

Performans Benchmark’ları, Sorgu Optimizasyonu ve Operasyonel Gerçeklik

ClickHouse’un public benchmark suite’i olan clickbench.com, 100 milyon satırlık web analytics dataset’i üzerinde 43 sorgu çalıştırır ve tüm OLAP motorlarını karşılaştırır. 2025 Q4 sonuçlarına göre tek node 16 vCPU konfigürasyonda toplam çalışma süreleri (cold + hot):

Sistem	Cold Total (s)	Hot Total (s)	Disk Boyutu	Yıllık Lisans (TB)
ClickHouse 24.10	13.5	4.2	11 GB	$0 (OSS)
Apache Druid 30.x	78.2	15.3	16 GB	$0 (OSS)
Apache Pinot 1.2	62.5	11.8	14 GB	$0 (OSS)
StarRocks 3.x	22.4	6.1	13 GB	$0 (OSS)
DuckDB 1.1	9.8	3.5	10 GB	$0 (OSS)
Snowflake (M)	~30	~8	N/A	~$3000+
BigQuery	~25	~7	N/A	~$2400+

DuckDB tek node analitikte ClickHouse’a yakın hatta önde ancak distributed senaryoda devreye girmez; bu yüzden kıyaslama oturumda tek node’a sıkıştırılmış bir adil olmayan bir test ortamı gibi görünebilir. Çok node, gerçek production iş yükü ile gidildiğinde ClickHouse’un avantajı 5-10x’e çıkar. Güncel benchmark sonuçlarını ClickBench resmî sitesinden takip edebilirsiniz; metodoloji ve ham veri GitHub’da açıktır. Druid Pinot Trino federated query yazımda bu üç motoru ne zaman ClickHouse’a tercih etmeniz gerektiğini detayladım.

Sorgu optimizasyonunda dört temel kural vardır. Birincisi, EXPLAIN ve EXPLAIN PIPELINE ile sorgu planını her zaman kontrol et — özellikle indexes=1 bayrağı sparse index’in kaç granül atladığını gösterir. İkincisi, PREWHERE klauzü filtreleri kolon okumadan önce uygular; selektif filtrelerde 5-20x hızlandırma sağlar. Üçüncüsü, JOIN’lerde küçük tabloyu sağa koymak (right table önce belleğe alınır); ClickHouse 23.x’ten itibaren cost-based optimizer bunu otomatik yapsa da kompleks sorgularda manuel kontrol önemli. Dördüncüsü, LowCardinality(String) tipi tekrar eden değerlerde (event_type, country, status) 3-10x performans + 5-15x sıkıştırma sağlar — defaults olarak kullanmaya başlayın.

Operasyonel Gerçeklik: Backup, Monitoring, Upgrade

ClickHouse’u production’da çalıştırmanın gerçekleri her zaman sunum slaytlarındaki kadar parlak değildir. BACKUP komutu 22.8’den beri stabil ve S3’e doğrudan yazabiliyor, ancak büyük tablolarda incremental destek hâlâ olgunlaşma sürecinde. Pratik tavsiye: 5 TB’a kadar tablolar için native BACKUP, üstü için clickhouse-backup aracı (Altinity tarafından maintained, GitHub’da 2.5k+ yıldız).

1. Monitoring stack: Prometheus + ClickHouse Exporter + Grafana. system.metrics, system.events, system.asynchronous_metrics tabloları self-monitoring için yeterli.
2. Slow query log: system.query_log tablosu (kendisi MergeTree) sorgu performans tarihini saklar; haftalık partition ile 90 gün tutmak yeterli.
3. Mutations: ALTER UPDATE/DELETE asenkron, ağır maliyetli işlemlerdir. system.mutations üzerinden ilerlemeyi izle; üretimde gece pencerelerinde batch’le.
4. Upgrade stratejisi: Stable kanal üç ayda bir yeni minor sürüm yayınlar; LTS kanal yıllık. Production’da +1 ay bekleme önerilir.
5. Disaster recovery: ReplicatedMergeTree iki replika + S3 backup + farklı AZ; RPO 1 dakika, RTO 15 dakika hedefi gerçekçi.

Veri kalitesi tarafında ham event akışından önce Great Expectations veya Soda ile şema validation yapmak, downstream MV’lerin patlamasını önler. ClickHouse operasyonel best practice’lerinin canlı listesi resmî GitHub deposunda sürekli güncellenir. Ben Ömer Önal olarak müşterilere ClickHouse danışmanlığı verirken en sık şu üç hatayla karşılaşıyorum: çok dar primary key (cardinality eksik), partition’ın günlük tutulması (8000+ part oluşumu), AlterTable mutasyonlarının iş saatlerinde çalıştırılması.

ClickHouse vs Alternatifler: Karar Çerçevesi

ClickHouse her sorunun cevabı değildir. Aşağıdaki tablo, gerçek dünya senaryolarında hangi sistemin neden seçileceğini özetler. Bu çerçeve data lakehouse mimarisi ile birleşince modern stack’inizin neresinde ClickHouse’un yer alacağını netleştirir. Stack Overflow 2025 Developer Survey’in tam metodolojisini resmî yayın sayfasında inceleyebilirsiniz.

Senaryo	Tercih	Sebep
Real-time dashboard, <1s latency	ClickHouse	Sub-second OLAP’ın altın standardı.
Karmaşık BI raporları, JOIN ağırlıklı	Snowflake / BigQuery	Cost-based optimizer + auto-scaling daha olgun.
Federated query (S3 + RDBMS + Kafka)	Trino / Presto	ClickHouse multi-source JOIN’de zayıf.
Time-series, IoT, monitoring	ClickHouse / TimescaleDB	TTL + downsampling + columnar.
Sub-100ms dashboard, mobil app	Pinot	Star-tree index dashboard’lar için optimize.
Veri bilimi + ML (notebook bazlı)	Databricks / Snowflake	Python entegrasyonu ve MLflow olgun.
Transactional + analytical karışık	PostgreSQL + Citus	ACID + sharding bir arada.

2026’da net trend şu: ClickHouse, kafka ile birlikte real-time analytics’in fiili standart stack’i hâline gelirken; Snowflake/BigQuery kompleks BI ve veri paylaşımı için kalıcı; lakehouse’lar (Iceberg + Delta) bunların altında soğuk katman olarak yer alıyor. dbt analytics engineering ile transformasyon katmanını standardize ederseniz, ClickHouse’u SQL-only bir analitik veritabanı olarak operasyona almak haftalar değil günler alır.

Sık Sorulan Sorular (SSS)

Sonuç

ClickHouse 2026’da real-time analytics ve OLAP veri ambarı kategorisinde fiili standart konumunu sağlamlaştırdı. Sütun tabanlı mimari, MergeTree saklama motoru ailesi, vektörel SIMD yürütme, materialized view’lar ve native Kafka/S3 entegrasyonları birleştiğinde; petabayt ölçekli analitik iş yüklerini sub-second latency ile, klasik cloud warehouse’lara göre %60-80 daha düşük maliyetle çalıştırmak mümkün hâle gelir. ClickHouse Cloud’un olgunlaşması self-hosted operasyon yüküne girmek istemeyen ekipler için de cazip bir seçenek sundu.

Karar çerçevesi nettir: transactional iş yükü PostgreSQL’de kalır, karmaşık BI ve veri paylaşımı Snowflake/BigQuery’de yaşamaya devam eder, ancak dashboard, observability, real-time analytics ve event analytics için ClickHouse default seçim olmalıdır. Stream processing katmanınızı Kafka + Flink/Spark ile kurduğunuzda ClickHouse pipeline’ın doğal son durağıdır. Migrasyonu aşamalı planlayın: önce yeni bir kullanıcı yolu (örneğin event analytics) ClickHouse’a, ölçüm, başarı, sonra genişletme.

Mimari kararı verdiniz ama nereden başlayacağınızı bilmiyorsanız — primary key seçimi, sharding stratejisi, Kafka topic to MergeTree pipeline tasarımı, capacity planning, performans optimizasyonu — iletişim sayfasından ulaşabilirsiniz; gerçek üretim deneyimi taşıyan birlikteliğin pilot projeyi haftalardan günlere indirmesi tipik bir geri dönüştür.