ClickHouse nedir? Mimarisi, kullanım alanları ve

ClickHouse, büyük veri kümeleri üzerinde hızlı analitik sorgular çalıştırmak için tasarlanmış açık kaynaklı, sütun bazlı (column-oriented) bir OLAP veritabanıdır. SQL ile sorgulanabilir; özellikle gerçek zamanlı analitik, log ve observability verileri, event kayıtları, dashboard’lar ve büyük ölçekli raporlama iş yüklerinde kullanılır.

ClickHouse’ın güçlü olduğu alan, çok sayıda kayıt üzerinde filtreleme, toplulaştırma ve zaman aralığı sorgularını düşük gecikmeyle çalıştırmaktır. Bu nedenle klasik bir uygulama veritabanının birebir alternatifi olarak değil, çoğu mimaride analitik iş yüklerini üstlenen ayrı bir veri katmanı olarak değerlendirilmesi daha doğru olur.

Projenin güncel özellikleri ClickHouse’ın resmi ürün sayfasında, teknik ayrıntıları ise resmi ClickHouse dokümantasyonunda incelenebilir.

ClickHouse nedir?

ClickHouse, OLAP (Online Analytical Processing) iş yükleri için geliştirilmiş sütun bazlı bir veritabanı yönetim sistemidir. Geleneksel transactional veritabanlarında veriler çoğunlukla satır odaklı saklanırken, ClickHouse analitik sorguların ihtiyaç duyduğu sütunları verimli biçimde okuyabilecek şekilde tasarlanmıştır.

Bu yaklaşım özellikle yüz milyonlarca veya milyarlarca kayıt içerisinden belirli sütunları okuyarak SUM, COUNT, AVG, GROUP BY, filtreleme ve zaman bazlı analiz yapan sorgularda avantaj sağlar.

ClickHouse tek bir sunucuda çalışabileceği gibi, veri hacmi ve erişilebilirlik gereksinimlerine göre birden fazla node içeren dağıtık cluster mimarilerinde de kullanılabilir.

OLAP nedir ve nerede kullanılır?

OLAP sistemlerinin temel amacı tek bir kaydı bulup değiştirmekten çok, büyük veri kümeleri üzerinde analiz yapmaktır. OLTP (Online Transaction Processing) sistemleri ise sipariş oluşturma, müşteri kaydı güncelleme veya ödeme işlemi gibi sık ve küçük transaction’ları yönetmek üzere tasarlanır.

PostgreSQL veya MySQL gibi OLTP sistemleri ile ClickHouse bu nedenle doğrudan aynı problemi çözmek üzere geliştirilmiş ürünler değildir. Gerçek sistemlerde transactional veri PostgreSQL veya MySQL üzerinde tutulurken, analitik amaçla kullanılacak veri ClickHouse’a aktarılabilir.

OLTP ve OLAP arasındaki mimari farklar ClickHouse’ın OLTP ve OLAP rehberinde de ayrıntılı olarak açıklanmaktadır.

ClickHouse nasıl çalışır?

ClickHouse’ın performansı yalnızca “sütun bazlı olduğu için hızlı” şeklinde açıklanamaz. Veri disk üzerinde belirli bir düzende tutulur, data part’ları halinde yazılır ve arka planda birleştirilir. Sorgu motoru ise mümkün olduğunca ihtiyaç duyulmayan veri bloklarını okumamaya çalışır.

ClickHouse’ın en yaygın kullanılan table engine ailesi MergeTree‘dir.

MergeTree tablosuna veri yazıldığında immutable data part’ları oluşur. ClickHouse bu part’ları arka planda merge ederek daha büyük part’lar meydana getirir. Part içerisindeki satırlar ise granule adı verilen mantıksal okuma blokları halinde organize edilir.

Varsayılan granule büyüklüğü çoğu durumda 8.192 satırdır. Sparse primary index her satırı ayrı ayrı indexlemek yerine granule seviyesinde işaretler tutar. Bu yapı index’in çok büyük tablolarda dahi görece küçük kalmasına yardımcı olur.

Neden hızlıdır?

ClickHouse performansı tek bir optimizasyondan değil, birden fazla mimari kararın birlikte çalışmasından gelir.

• Column-oriented storage: Sorgunun ihtiyaç duyduğu sütunların okunmasını sağlar.
• Veri sıkıştırma: Aynı tipteki değerlerin birlikte tutulması sıkıştırma verimliliğini artırabilir.
• ORDER BY: Verinin fiziksel sıralamasını belirler ve sorgu pattern’leriyle doğru eşleştiğinde büyük veri aralıklarının atlanmasını sağlar.
• Sparse primary index: Her satırı indexlemek yerine granule seviyesinde veri elemesine yardımcı olur.
• Vectorized execution: Verinin satır satır yerine bloklar halinde işlenmesini sağlar.
• Parallel execution: Sorgular CPU kaynaklarını paralel kullanabilir.
• Background merges: Yazma sırasında oluşan part’lar arka planda birleştirilir.

ClickHouse’ın güncel query optimization rehberlerinde de doğru veri sıralamasının ve primary index tasarımının performans üzerindeki temel faktörlerden biri olduğu vurgulanmaktadır. Ayrıntılı teknik açıklamalar ClickHouse query optimization rehberinde incelenebilir.

Ne işe yarar?

ClickHouse’ın güçlü olduğu senaryolar, yüksek miktarda verinin toplandığı ve bu veri üzerinde hızlı analitik sorguların çalıştırılması gereken sistemlerdir.

Yaygın kullanım alanları arasında şunlar bulunur:

• Gerçek zamanlı analitik ve kullanıcıya açık dashboard’lar,
• Log, metric ve trace verilerinin analizi,
• Web ve mobil uygulama event’leri,
• Kullanıcı davranışı ve clickstream analizi,
• Reklam ve pazarlama analitiği,
• IoT ve telemetri verileri,
• Fraud ve güvenlik olaylarının analizi,
• Data warehouse ve büyük ölçekli BI iş yükleri,
• Zaman serisi niteliğindeki yüksek hacimli kayıtların analizi.

ClickHouse’ın resmi kullanım alanları arasında da real-time analytics, observability, data warehousing ve yüksek hacimli analitik uygulamalar öne çıkmaktadır.

Hangi iş yükleri için uygundur?

Hangi durumlarda gerekli olmayabilir?

ClickHouse güçlü bir analitik veritabanıdır; ancak sisteme yeni bir database eklemek kendi başına mimari iyileştirme anlamına gelmez.

Mevcut PostgreSQL, MySQL veya başka bir veri katmanı mevcut veri hacmini ve analitik sorgu yükünü hedeflenen gecikme seviyelerinde karşılıyorsa ikinci bir database platformunun sağlayacağı fayda ile getireceği operasyon yükü birlikte değerlendirilmelidir.

Yeni bir ClickHouse ortamı yalnızca query performance konusu değildir. Deployment, monitoring, backup, access control, upgrade, kapasite planlama ve operasyon bilgisi de gerektirir.

Özellikle aşağıdaki workload’larda ClickHouse kararı ayrıca değerlendirilmelidir:

• Ana iş yükü yoğun OLTP ve kısa transaction işlemlerinden oluşuyorsa,
• Uygulama çoğunlukla tekil kayıt sorguları ve sık row-level değişiklikler yapıyorsa,
• Mevcut veri hacmi kullanılan veritabanı için henüz operasyonel problem oluşturmuyorsa,
• Analitik sorgular mevcut altyapıda hedeflenen performansı karşılıyorsa,
• Yeni bir database sistemini yönetecek operasyon kapasitesi bulunmuyorsa.

ClickHouse PostgreSQL yerine geçer mi?

Çoğu sistemde ClickHouse ve PostgreSQL birbirinin doğrudan alternatifi değildir.

PostgreSQL genel amaçlı relational database olarak transaction, point lookup, constraint ve yoğun row-level işlem gerektiren uygulamalarda güçlüdür. ClickHouse ise büyük veri kümeleri üzerinde analitik sorgular çalıştırmaya odaklanır.

PostgreSQL bazı extension ve scale-out çözümleriyle daha geniş analitik workload’ları destekleyebilir. Ancak ClickHouse storage ve query execution mimarisini baştan itibaren analitik OLAP workload’ları için tasarlamıştır.

Yaygın mimarilerden biri PostgreSQL veya MySQL’in transactional sistem olarak kalması ve verinin Change Data Capture (CDC) veya streaming altyapısı üzerinden ClickHouse’a taşınmasıdır.

UPDATE ve DELETE yapılabilir mi?

Evet. ClickHouse’ta veri değiştirme ve silme mekanizmaları bulunmaktadır ve son sürümlerde bu yetenekler önemli ölçüde geliştirilmiştir.

Bununla birlikte “ClickHouse UPDATE destekliyor” ifadesi, sistemin PostgreSQL veya MySQL ile aynı transactional workload profiline sahip olduğu anlamına gelmez.

ClickHouse’ın storage ve query mimarisi hala büyük analitik veri kümeleri üzerinde yüksek performansa odaklanır. Uygulamanın ana iş yükü sürekli tekil kayıt güncellemek, kısa transaction’lar yürütmek ve point lookup yapmaksa sistem seçimi bu özellikler üzerinden değerlendirilmelidir.

Veri nasıl yazılmalıdır?

ClickHouse yüksek hacimli ingestion işlemlerini destekler. Ancak veri yazma modelinin MergeTree mimarisiyle uyumlu olması önemlidir.

Insert işlemleri data part oluşumuna yol açar. Çok sayıda küçük synchronous insert, part’ların merge edilebildiğinden daha hızlı oluşmasına ve gereksiz merge baskısına neden olabilir.

ClickHouse 26.3 LTS sürümüyle birlikte asynchronous insert mekanizmasını varsayılan olarak etkinleştirmiştir. Bu yapı sık ve küçük insert’leri server tarafında buffer ederek daha büyük yazma işlemleri halinde birleştirmeye yardımcı olur.

Değişikliğin teknik ayrıntıları ClickHouse 26.3 sürüm notlarında açıklanmaktadır.

Asynchronous insert mekanizması küçük insert problemini önemli ölçüde kolaylaştırmış olsa da ingestion mimarisinin veri hacmi ve kaynak sistemlere göre tasarlanması gerekir.

Kafka ve stream processing içeren daha geniş veri pipeline’larıyla çalışan ekipler, Absonet Hadoop, Kafka ve Spark Veri Altyapı Eğitimi içeriğini de inceleyebilir.

Partitioning performansı artırır mı?

Her zaman değil.

ClickHouse’ta partitioning çoğunlukla veri yaşam döngüsü ve data management amacı taşır. PostgreSQL gibi sistemlerden gelen “daha fazla partition daha hızlı sorgu” yaklaşımının ClickHouse’a doğrudan taşınması doğru değildir.

High-cardinality kolonlarla veya gereğinden ince zaman aralıklarıyla aşırı partition oluşturmak çok sayıda küçük part meydana gelmesine, merge süreçlerinin zorlaşmasına ve kaynak tüketiminin artmasına neden olabilir.

ClickHouse’ın güncel best-practice rehberi de partitioning’i genel amaçlı bir query performance optimizasyonu olarak değil, öncelikle veri yönetimi özelliği olarak ele almaktadır. Ayrıntılar ClickHouse best practices dokümanında incelenebilir.

ORDER BY neden kritiktir?

ClickHouse’ta MergeTree tablo tanımındaki ORDER BY, SQL sorgusunun sonunda kullanılan ORDER BY ile karıştırılmamalıdır.

MergeTree ORDER BY ifadesi verinin storage üzerinde hangi sırada tutulacağını belirleyen temel tasarım kararlarından biridir.

Sık kullanılan filtre kolonlarının doğru sırada seçilmesi, primary index yardımıyla çok sayıda granule’ın okunmadan atlanmasını sağlayabilir.

Bu nedenle tablo tasarlarken ORDER BY ifadesini yalnızca kolon cardinality’sine bakarak değil, gerçek uygulamanın query pattern’lerine göre belirlemek gerekir.

JSON ve yarı yapısal veriler kullanılabilir mi?

Evet. ClickHouse özellikle log, event ve telemetry workload’larında sık karşılaşılan JSON verileriyle çalışabilir.

Yeni nesil JSON data type, 25.3 sürümünden itibaren production-ready olarak sunulmaktadır. JSON path’leri column-oriented biçimde saklanabilir ve dinamik yapıya sahip payload’lar üzerinde analitik sorgular çalıştırılabilir.

Bununla birlikte bütün JSON payload’ını hiçbir modelleme yapmadan tek kolona atmak her workload için doğru yaklaşım değildir. Sık kullanılan alanların veri tipleri, query pattern’leri ve cardinality değerleri yine incelenmelidir.

JSON data type’ın güncel davranışı resmi ClickHouse JSON dokümantasyonunda yer almaktadır.

Elasticsearch yerine kullanılabilir mi?

Bazı log analytics ve observability projelerinde evet; ancak iki sistemi bütün kullanım alanları için birebir alternatif olarak değerlendirmek doğru değildir.

Elasticsearch arama ve document-oriented kullanım senaryolarında uzun süredir güçlü bir ekosisteme sahiptir. ClickHouse ise logların filtrelenmesi, sayılması, gruplanması ve zaman içerisinde analiz edilmesi gibi analitik işlemlerde doğal olarak güçlüdür.

ClickHouse’ın 2026’da production-ready hale gelen full-text search yetenekleriyle birlikte, özellikle log analytics senaryolarında Elasticsearch alternatifi olarak değerlendirilmesi daha anlamlı hale gelmiştir.

ClickHouse ekibi 2026 yılında OpenTelemetry log verileri üzerinde kendi Elasticsearch karşılaştırmasını da yayımlamıştır. Bu sonuçlar ürün üreticisinin kendi benchmark’ı olduğu için bağımsız benchmark gibi değerlendirilmemelidir; ancak test metodolojisi ve sorgu tipleri teknik karşılaştırma yapmak isteyen ekipler için yararlı bir referans sağlar. ClickHouse Elasticsearch log analytics karşılaştırması üzerinden test ayrıntıları incelenebilir.

Karar verirken yalnızca query latency değil; full-text search gereksinimleri, mevcut Kibana/Elastic entegrasyonları, retention politikası, ingestion mimarisi, storage maliyeti ve ekibin operasyon yetkinliği birlikte değerlendirilmelidir.

Cloud ile self-hosted arasındaki fark nedir?

ClickHouse açık kaynak olarak kendi altyapınızda çalıştırılabileceği gibi ClickHouse Cloud üzerinden yönetilen servis olarak da kullanılabilir.

SharedMergeTree nedir?

ClickHouse Cloud tarafında kullanılan SharedMergeTree, storage ile compute katmanlarının birbirinden ayrılmasına imkan veren bir table engine mimarisidir.

Tablo verileri shared object storage üzerinde tutulurken compute node’ları bu verilere ortak olarak erişebilir. Böylece storage kapasitesi ile compute kaynakları birbirinden bağımsız ölçeklenebilir.

Bu yapı klasik self-hosted MergeTree deployment modeliyle aynı değildir. Bu nedenle ClickHouse Cloud mimarisindeki SharedMergeTree davranışlarını bütün self-managed ClickHouse cluster’larına genellememek gerekir.

ClickHouse Cloud’un storage/compute separation mimarisi SharedMergeTree ve stateless compute mimarisi dokümanında ayrıntılı olarak açıklanmaktadır.

Kubernetes üzerinde çalışır mı?

Evet. ClickHouse Kubernetes üzerinde çalıştırılabilir.

ClickHouse, 2026 yılında açık kaynaklı Official ClickHouse Kubernetes Operator projesini yayımlamıştır. Operator, ClickHouse kaynaklarının Kubernetes CRD’leri üzerinden tanımlanmasına ve cluster operasyonlarının otomasyonuna yardımcı olur.

Bununla birlikte stateful bir database’in Kubernetes üzerinde çalıştırılması persistent storage, node failure, backup, resource scheduling, upgrade ve performans tasarımı gibi konuları ortadan kaldırmaz.

Kubernetes deployment modelini kolaylaştırabilir; database storage ve operasyon mimarisinin yerine geçmez.

Resmi proje duyurusu ve mimari ayrıntılar ClickHouse Kubernetes Operator sayfasında yer almaktadır.

Cluster olarak nasıl ölçeklenir?

ClickHouse tek node’lu sistemlerden çok node’lu dağıtık yapılara kadar farklı ölçeklerde çalışabilir.

Self-hosted yapılarda sharding, veri setinin farklı node’lar arasında dağıtılması için; replication ise veri kopyalarının birden fazla replica üzerinde tutulması için kullanılabilir.

Ancak cluster tasarımı yalnızca node sayısını artırmak değildir.

Production tasarımında en az şu başlıklar birlikte değerlendirilmelidir:

• Shard ve replica sayısı,
• Veri dağılımı,
• Query routing,
• Disk throughput ve kapasite,
• Network kapasitesi ve latency,
• CPU ve memory kaynakları,
• Failure senaryoları,
• Backup ve restore süreci,
• Monitoring ve alerting.

Nasıl kullanılır?

ClickHouse kullanımında ilk adım database’i kurmak değil, analitik workload’u tanımlamaktır.

Basitleştirilmiş bir çalışma sırası şu şekildedir:

1. Kaynak verinin ve ingestion hızının belirlenmesi,
2. En sık çalışacak analitik sorguların çıkarılması,
3. Bu sorgulara uygun MergeTree tablo yapısının tasarlanması,
4. ORDER BY ve gerekiyorsa partition anahtarlarının belirlenmesi,
5. Batch veya asynchronous ingestion yönteminin yapılandırılması,
6. Gerçek veri üzerinde sorgu ve kaynak tüketiminin ölçülmesi,
7. Gerekliyse materialized view, projection veya ek index yapılarına geçilmesi.

Örneğin event tablosunda son bir saat içerisindeki kayıtların dakika bazında sayılması tipik bir analitik sorgudur:

SELECT
    toStartOfMinute(event_time) AS minute,
    count() AS event_count
FROM events
WHERE event_time >= now() - INTERVAL 1 HOUR
GROUP BY minute
ORDER BY minute;

Bu sorgu basit görünse de gerçek performans; tablonun ORDER BY tasarımına, veri hacmine, kullanılan kolonlara, part yapısına ve donanıma bağlıdır.

Sık yapılan tasarım hataları

• ClickHouse’ı transactional database’in doğrudan yerine koymaya çalışmak,
• Uygulamanın query pattern’lerini incelemeden ORDER BY belirlemek,
• Primary key’i OLTP veritabanlarındaki uniqueness constraint gibi değerlendirmek,
• Eski deployment alışkanlıklarıyla çok sayıda küçük synchronous insert göndermek,
• High-cardinality değerlerle gereğinden fazla partition oluşturmak,
• Her performans sorununa materialized view veya ek index ile cevap vermek,
• Shard sayısını yalnızca storage kapasitesine göre belirlemek,
• Query concurrency’yi kapasite planlamasına dahil etmemek,
• Monitoring, backup ve disaster recovery tasarımını kurulum sonrasına bırakmak,
• Benchmark sonuçlarını kendi workload’u üzerinde doğrulamadan doğrudan kapasite hedefi olarak kullanmak.

İşletmeniz için mantıklı mı?

Bu sorunun cevabı yalnızca toplam veri miktarına bakılarak verilmemelidir. Asıl belirleyici workload’un niteliğidir.

Yüksek hacimli event kaydı tutan, kullanıcıya gerçek zamanlı dashboard sunan, büyük log ve telemetry verileri üzerinde sürekli filtreleme ve aggregation sorguları çalıştıran sistemlerde ClickHouse güçlü bir adaydır.

Buna karşılık transactional ağırlıklı bir uygulamada, düşük analitik yükte veya mevcut database’in sorgu gereksinimlerini hedeflenen gecikme seviyelerinde karşılayabildiği bir ortamda ClickHouse eklemek gerekli olmayabilir.

Teknoloji seçimi öncesinde şu soruların cevaplanması yararlıdır:

• Günlük ne kadar veri üretiliyor?
• Veri ne kadar süre saklanacak?
• En sık çalışan sorgular hangi kolonlarda filtreleme yapıyor?
• Sorgular ne kadar aggregation içeriyor?
• Beklenen query latency nedir?
• Veri ağırlıklı olarak append ediliyor mu, yoksa sürekli değişiyor mu?
• Kaç eş zamanlı kullanıcı veya servis sorgu çalıştıracak?
• Mevcut database’deki gerçek darboğaz nedir?
• ClickHouse self-hosted çalıştırılacaksa sistemi yönetecek operasyon yetkinliği mevcut mu?

ClickHouse hakkında sık sorulan sorular

ClickHouse açık kaynak mı?

Evet. ClickHouse açık kaynaklı, column-oriented bir analitik database’dir. Self-managed olarak çalıştırılabilir veya ClickHouse Cloud üzerinden managed servis olarak kullanılabilir.

SQL destekliyor mu?

Evet. ClickHouse SQL tabanlı bir sorgu dili kullanır. Ancak bazı database davranışları, data type’lar, index yapıları ve optimizasyon yöntemleri PostgreSQL veya MySQL’den farklıdır.

ClickHouse PostgreSQL yerine kullanılabilir mi?

Bazı workload’lar taşınabilir ancak ClickHouse genel olarak PostgreSQL’in birebir replacement’ı olarak değerlendirilmemelidir. PostgreSQL transactional ve genel amaçlı relational workload’larda, ClickHouse ise analitik OLAP workload’larında öne çıkar. İki sistem aynı mimaride birlikte de kullanılabilir.

Log analizi için uygun mu?

Evet. Büyük hacimli log, metric, trace ve diğer observability verilerinin analizi ClickHouse’ın yaygın kullanım alanlarından biridir.

Real-time analytics için uygun mu?

Evet. ClickHouse sürekli gelen büyük veri üzerinde düşük gecikmeli analitik sorgular ve kullanıcıya açık dashboard’lar için kullanılabilir.

UPDATE ve DELETE destekliyor mu?

Evet. Güncel ClickHouse sürümlerinde UPDATE ve DELETE için farklı mekanizmalar bulunmaktadır. Bununla birlikte yoğun row-level transaction workload’u ile büyük analitik workload aynı problem değildir; sistem seçimi yalnızca UPDATE komutunun mevcut olup olmadığına göre yapılmamalıdır.

Küçük projelerde kullanılabilir mi?

Teknik olarak evet. Ancak mevcut database’in veri hacmini ve sorgu yükünü rahatlıkla karşıladığı küçük sistemlerde ayrı bir ClickHouse platformunun operasyon maliyeti sağlayacağı avantajdan daha yüksek olabilir.

Sadece log verisi için mi kullanılır?

Hayır. Log ve observability önemli kullanım alanlarıdır ancak ClickHouse aynı zamanda real-time analytics, data warehousing, event analytics, IoT, kullanıcı davranışı analizi ve yüksek hacimli BI workload’larında da kullanılabilir.

Cloud kullanmak zorunlu mu?

Hayır. ClickHouse açık kaynak olarak kurumun kendi altyapısında çalıştırılabilir. ClickHouse Cloud ise altyapı ve database operasyonunun önemli bölümünü managed servis olarak sağlayan ayrı bir deployment modelidir.

Sonuç

ClickHouse; büyük veri kümeleri üzerinde düşük gecikmeli analitik sorgular çalıştırılması gereken sistemler için güçlü bir seçenektir. Column-oriented storage, MergeTree mimarisi, sparse primary index, data skipping ve paralel query execution yaklaşımı özellikle aggregation ağırlıklı OLAP workload’larında önemli avantaj sağlar.

Ancak doğru sonuç almak için yalnızca ClickHouse kurmak yeterli değildir. Veri modeli, ORDER BY seçimi, ingestion yöntemi, partition tasarımı, query concurrency ve operasyon mimarisi workload’a göre planlanmalıdır.

Kurumsal bir ClickHouse veya benzeri veri altyapısı değerlendirilirken mevcut transactional sistemler, veri hacmi, sorgu profili, ingestion kaynakları ve altyapı gereksinimlerinin birlikte ele alınması gerekir.

Kafka, Spark ve dağıtık veri işleme mimarileriyle ilgili uygulamalı içerikler için Hadoop, Kafka ve Spark Veri Altyapı Eğitimi sayfamızı; açık kaynak altyapılarının tasarım ve operasyon ihtiyaçları için ise Absonet danışmanlık hizmetlerini inceleyebilirsiniz.

Diğer Linux, Kubernetes, veri altyapısı ve açık kaynak içerikleri için Absonet Teknik Rehberler bölümüne göz atabilirsiniz.