ClickHouse Dağıtık Tablo Mimarisinde Data Skew: Sharding Key Seçimi ve Resharding Stratejileri
Blog'a Dön

ClickHouse Dağıtık Tablo Mimarisinde Data Skew: Sharding Key Seçimi ve Resharding Stratejileri

Buğra Şıkel

ClickHouse Dağıtık Tablo Mimarisinde Data Skew: Sharding Key Seçimi ve Resharding Stratejileri

Giriş

ClickHouse, devasa veri setlerini yatayda ölçeklendirmek için sharding (parçalama) mekanizmasını kullanır. Dağıtık tablo mimarisi (Distributed Table Architecture), veriyi birden fazla node üzerine yayarak paralel işleme imkanı sunar. Ancak, bu mimarinin verimli çalışması, verinin shardlar arasında ne kadar dengeli dağıldığına bağlıdır. Veri dengesizliği, yani data skew, bir node’un diğerlerinden çok daha fazla veri barındırması ve sorgu yükünün o node üzerinde yoğunlaşması durumudur.

İçindekiler

  • Data Skew Nedir ve Neden Tehlikelidir?
  • Sharding Key Seçiminde Kritik Faktörler
  • Dengeli Dağılım İçin Hashing Fonksiyonları
  • Resharding: Mevcut Veriyi Yeniden Dağıtma Stratejileri
  • Sıkça Sorulan Sorular (SSS)
  • Sonuç

Data Skew Nedir ve Neden Tehlikelidir?

Data skew, distributed bir sistemde verilerin belirli shard’larda kümelenmesi durumudur. ClickHouse’da bu durum genellikle yanlış seçilmiş bir sharding key sonucunda oluşur. Eğer sorgularınızda en çok kullanılan filtreleme alanı (örneğin customer_id veya region) heterojen bir dağılıma sahipse, bazı node’lar TB’larca veriyle dolarken diğerleri boş kalabilir.

Bu dengesizlik, ‘en yavaş node kadar hızlısınız’ kuralı gereği, tüm kümenin sorgu performansını en ağır shard’ın hızına düşürür.

Sharding Key Seçiminde Kritik Faktörler

Doğru sharding key seçimi, sadece veri dağılımını değil, aynı zamanda JOIN operasyonlarının ve aggregation işlemlerinin performansını da belirler.

1. Yüksek Kardinaliteye Sahip Alanlar

Düşük kardinaliteli alanlar (örneğin ‘gender’ veya ‘is_active’) shard sayısından az benzersiz değere sahipse, verinin sadece birkaç node’a sıkışmasına neden olur. Bunun yerine, UUID, user_id veya timestamp gibi yüksek varyasyonlu alanlar tercih edilmelidir.

2. Sorgu Modelleriyle Uyum

Eğer verileriniz genellikle belirli bir anahtar üzerinden sorgulanıyorsa, o anahtarı sharding key olarak seçmek, ‘locality’ sağlar. Ancak bu anahtar dengesizse, cityHash64() gibi fonksiyonlarla normalize edilmelidir.

Dengeli Dağılım İçin Hashing Fonksiyonları

ClickHouse’da sharding ifadesi (sharding_key) genellikle bir tamsayı veya bir hash fonksiyonu çıktısıdır. Rastgele bir dağılım için rand() kullanılabilir, ancak bu durum sorgu performansını (co-location avantajını) öldürür. En yaygın ve performanslı yöntem şudur:

  • cityHash64(identifier): String tabanlı anahtarları sayısal değerlere dönüştürerek homojen bir dağılım sağlar.
  • intHash64(id): Sayısal ID’leri karmaşıklaştırarak ardışık yüklemelerde yığılmayı önler.

Resharding: Mevcut Veriyi Yeniden Dağıtma Stratejileri

ClickHouse’da veriyi canlı bir sistemde yeniden dağıtmak (resharding) karmaşık bir işlemdir çünkü yerleşik bir ‘auto-rebalance’ özelliği sınırlıdır. İşte uygulanabilecek stratejiler:

1. Yeni Tabloya Kopyalama (Insert Into Select)

En güvenli yöntem, yeni bir sharding key ile yeni bir tablo oluşturmak ve veriyi INSERT INTO new_table SELECT * FROM old_table komutuyla aktarmaktır. Bu işlem sırasında kaynak tüketimini sınırlamak için max_insert_threads ayarı optimize edilmelidir.

2. ClickHouse Copier Tool

Resharding işlemini daha profesyonel yönetmek için clickhouse-copier aracı kullanılır. Bu araç, ZooKeeper üzerinden koordine olarak veriyi bir cluster’dan diğerine veya aynı cluster içindeki yeni bir şemaya güvenli bir şekilde taşır.

Sıkça Sorulan Sorular (SSS)

  • S: Sharding key değiştirilebilir mi?

    C: Mevcut bir tabloda sharding key doğrudan değiştirilemez. Yeni bir tablo oluşturup veriyi taşımanız gerekir.
  • S: rand() fonksiyonu sharding key olarak kullanılmalı mı?

    C: Sadece verinin eşit dağılması tek önceliğinizse kullanılabilir. Ancak bu, belirli bir ID’ye ait verilerin tüm shard’lara yayılmasına neden olarak sorgu performansını düşürür.
  • S: Bir node dolduğunda ne yapmalıyım?

    C: Geçici çözüm olarak shard ağırlıklarını (weight) değiştirebilirsiniz, ancak kalıcı çözüm resharding yapmaktır.

Sonuç

ClickHouse dağıtık mimarisinde data skew problemini aşmak, doğru tasarım kararlarıyla başlar. Sharding key seçerken kardinalite ve sorgu alışkanlıklarını dengelemek, uzun vadede operasyonel yükü azaltır. Mevcut dengesizlik durumlarında ise clickhouse-copier gibi araçlarla planlı bir resharding stratejisi izlemek, sistemin sürekliliği için kritiktir.

Bunları da beğenebilirsiniz

PHP ile Küfür Ayıklama Fonksiyonu
16 Ocak 2023

PHP ile Küfür Ayıklama Fonksiyonu

Merhabalar, bu yazımızda PHP ile küfür, hakaret içeren metinleri ayıklayan bir fonksiyon yazacağız. Genellikle projelerimizde yorum alanları gibi herkesin görebileceği alanlara kullanıcılarımız içerikler yazıyor. Bu…

Devamını Oku
Javascript ile Şifre Oluşturma Fonksiyonu
14 Ekim 2022

Javascript ile Şifre Oluşturma Fonksiyonu

Merhabalar, bu yazımızda javascript ile şifre oluşturucu bir fonksiyon yazıyoruz. Bu fonksiyonumuzun amacı kullanıcıların kendilerine ya da bizim onlar için anlık rastgele şifreler oluşturmamızı ve…

Devamını Oku
Edge Cihazlarda YOLOv8 ile Gerçek Zamanlı Nesne Tespiti: Docker ve NVIDIA Jetson Üzerinde Performans Optimizasyonu
29 Ocak 2026

Edge Cihazlarda YOLOv8 ile Gerçek Zamanlı Nesne Tespiti: Docker ve NVIDIA Jetson Üzerinde Performans Optimizasyonu

Bu kapsamlı rehberde, YOLOv8 modelini kullanarak NVIDIA Jetson edge cihazlarda gerçek zamanlı nesne tespitini nasıl optimize edeceğinizi öğreneceksiniz. Docker ve TensorRT entegrasyonuyla performansı zirveye taşıyın.

Devamını Oku
AI Asistan