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 Sayısal Para Değerinin Okunuşunu Yazdırmak
19 Mart 2023

PHP ile Sayısal Para Değerinin Okunuşunu Yazdırmak

Merhabalar, bu yazımızda bir para miktarı girildiğinde bunun okunuşunu ya da yazılışı da diyebiliriz, bize çıktı olarak verecek bir php fonksiyonu yazacağız. Türkçe bir şekilde…

Devamını Oku
PHP PDO ile Veritabanı İşlemleri
6 Aralık 2022

PHP PDO ile Veritabanı İşlemleri

Merhaba, veritabanı işlemlerini kolayca yapmanız için gereken her şeyi sunan PHP PDO hakkında bildiklerimi bu makalemizde sizlerle paylaşıyor olacağım. PHP PDO sayesinde veritabanınızı kontrol edebilir,…

Devamını Oku
REACT useState() Kullanımı
23 Ekim 2022

REACT useState() Kullanımı

Merhabalar, bu yazımızda React useState() hook’u inceleyeceğiz, ne olduğuna ve kullanımına bakacağız. React useState() Hook, bir fonksiyon bileşenindeki durumu izlememizi sağlar. Durum genellikle bir uygulamada…

Devamını Oku
Ask AI