ClickHousePerformans ve kapasite 15 dk 15.06.2026

ClickHouse ölçeklenebilirlik: shard, replica, Distributed table ve veri modeli

ClickHouse büyük okuma için güçlüdür; ama iyi ölçeklenmesi shard sayısından önce veri modeline bağlıdır. Yanlış partition, küçük insertler, zayıf ORDER BY ve gereksiz JOIN yükü varsa cluster büyür ama sorgular beklenen kadar rahatlamaz.

Bu yazı sana şu durumda yardımcı olur

ClickHouse sorguları veri büyüdükçe yavaşlıyor
tek node sınırına yaklaşılıyor
shard ve replica farkı karışıyor
Distributed table sorguları beklenenden pahalı
küçük insertler merge baskısı yaratıyor

Yazıyı bitirince

ClickHouse’ta shard, replica ve Distributed table kararlarını; veri modeli, insert deseni ve rapor sorgularıyla birlikte değerlendirebileceksiniz.

TürkDB açısından ürünleşme notu

Bu bölüm, TürkDB’nin ilgili problemi hangi ürün ilkeleri ve kontrol noktalarıyla ele alacağını anlatır. Kapsam, gerçek iş yükü ve ihtiyaçla birlikte netleşir.

TürkDB ClickHouse tarafında kapasite, yedek, olay ve sorgu sinyallerini görünür kılmayı hedefler. Shard/replica kararı ise gerçek rapor sorguları, veri hacmi ve kabul edilebilir maliyetle birlikte verilmelidir.

Shard ve replica farklı sorulara cevap verir

Shard, veriyi parçalara bölerek kapasiteyi yatay büyütür. Replica ise erişilebilirlik ve okuma kapasitesi için aynı verinin kopyasını tutar. İki kavram birlikte kullanılır ama aynı problemi çözmez.

Eğer veri tek node disk ve CPU sınırına yaklaşıyorsa shard gündeme gelir. Eğer erişilebilirlik ve okuma dayanıklılığı isteniyorsa replica konuşulur.

Shard: veri ve sorgu yükünü bölmek için.
Replica: erişilebilirlik ve bazı okuma senaryoları için.
Distributed table: shardlar üzerinde sorgu çalıştırmak için.
Yanlış veri modeli, shard ekleseniz de pahalı kalabilir.

Önce MergeTree tasarımını düzeltin

ClickHouse ölçeklenebilirliği ORDER BY, partition, primary key pruning ve veri tipi kararlarına çok bağlıdır. Sorgularınız tenant_id ve tarih aralığıyla çalışıyorsa tablo düzeni bunu desteklemelidir.

Sık kullanılan panolar için projection, materialized view veya özet tablo gerekebilir. Her raporu ham event tablosundan okumak, cluster büyüdükçe maliyeti artırır.

Distributed table ne zaman pahalılaşır?

Distributed table sorguyu shardlara dağıtır ve sonuçları toplar. Eğer sorgu doğru filtrelerle shardları daraltamıyorsa çok fazla veri ağ üzerinden taşınabilir. Bu durum özellikle geniş JOIN veya yüksek kardinaliteli group by sorgularında görünür.

Bu nedenle shard key, ORDER BY ve sorgu deseni birlikte düşünülmelidir. Sadece node sayısını artırmak ağ ve koordinasyon maliyetini de artırabilir.

Shard karar notu

clickhouse-shard-decision.md

En büyük tablo:
Günlük veri girişi:
En sık sorgu filtreleri:
ORDER BY:
Partition:
Tahmini veri saklama süresi:
Tek node sınırı: disk / CPU / bellek / insert
Shard adayı:
Replica ihtiyacı:

Kullanım örneği: SaaS analitik panosu

SaaS ürününde her tenant için event akıyorsa ClickHouse iyi bir adaydır. Sorgular çoğu zaman tenant_id, event_date ve event_name ile filtrelenir. Tablo düzeni bu filtreleri desteklerse çok büyük veri bile daha az satır okuyarak cevaplanabilir.

Tenantlar arasında veri hacmi çok dengesizse tek büyük tenant bazı shardları ısıtabilir. Bu durumda shard key ve tenant dağılımı ayrıca ölçülmelidir.

Devam etmek istersen

Sorunu motor bazında derinleştirin

Benzer belirtiler farklı motorlarda farklı nedenlere dayanır; yayınlanan tüm rehberleri ana sayfadan takip edebilirsiniz.

Tüm makaleler