ClickHouse daha tembel ve daha hızlı hale geliyor - gecikmeli yükleme optimizasyonu tanıtıldı

 (clickhouse.com)
6 puan yazan GN⁺ 2025-04-24 | 2 yorum | WhatsApp'ta paylaş
  • ClickHouse, yeni bir optimizasyon tekniği olan lazy materialization ile Top N sorgu performansını 1.500 kata kadar artırıyor
  • Sütun verisini yalnızca gerektiğinde okuma stratejisi ile disk I/O'sunu en aza indiriyor
  • Mevcut kolon tabanlı depolama, indeksler ve PREWHERE teknikleriyle birlikte katmanlı bir I/O optimizasyon yığını oluşturuyor
  • Sorgu yürütme planına göre sütun verisini gecikmeli yükleyerek, özellikle LIMIT ifadesi içeren sorgularda büyük fayda sağlıyor
  • Varsayılan olarak etkin olduğundan, kod değişikliği olmadan performans artışı elde edilebiliyor

ClickHouse'un gecikmeli optimizasyon stratejisi: Lazy Materialization

Temel kavram

  • ClickHouse, gereksiz veriyi okumayarak performansı en üst düzeye çıkarır
  • lazy materialization, sorgu yürütme sırasında sütun verisinin yalnızca gerçekten gerektiği anda yüklenmesi yaklaşımıdır
  • Mevcut I/O optimizasyon teknikleriyle bağımsız çalışırken birbirini tamamlayan performans artışları sağlar

Mevcut I/O optimizasyon teknikleri

  • Kolon tabanlı depolama: yalnızca gerekli sütunlar okunur
  • Sparse Index / Skipping Index / Projections: filtre koşullarına uyan granule'lar okunur
  • PREWHERE: indekslenmemiş sütunlar erken aşamada filtrelenir
  • Query Condition Cache: yinelenen sorguların sonucunu önbelleğe alarak aynı granule'ların yeniden işlenmesini önler

Lazy Materialization nasıl çalışır

  • Mevcut teknikler filtreleme yoluyla I/O azaltmaya odaklanırken, lazy materialization okumayı hesaplama anına kadar erteler
  • Sorgunun bir sonraki aşamasının ihtiyaç duyduğu sütunlar hemen okunur, geri kalanı ise LIMIT sonrasında gerektiğinde okunur
  • Özellikle Top N sorgularında yalnızca bazı sütunlar görüntülendiği için, büyük metin sütunları gibi veriler neredeyse hiç okunmaz

> Bu optimizasyon, sütunların bağımsız saklanması sayesinde mümkündür ve satır tabanlı veritabanlarında mümkün olmayan bir yaklaşımdır

Gerçek örnek: Amazon inceleme veri kümesi

  • 150M satır, sıkıştırılmamış 70GB, sıkıştırılmış 30GB

  • Top N sorgu örneği:

    SELECT helpful_votes  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3;
    • Çalışma süresi: 0,07 saniye
    • Yalnızca ilgili sütun sorgulandığı için yüksek hızda işlenir

  • Büyük metin sütunu sorgulama örneği:

    SELECT review_body  
FROM amazon.amazon_reviews  
FORMAT Null;
    • Çalışma süresi: 176 saniye
    • Tek sütun olmasına rağmen 56GB boyut nedeniyle disk I/O darboğazı oluşur

Optimizasyon katmanlarına göre performans karşılaştırması

1. Optimizasyon yok (Baseline)

  • Çalışma süresi: 219 saniye
  • İşlenen veri: 72GB, 150M satır
  • Tüm sütunlar okunur ve sıralanır

2. Primary Key Index uygulanmış

  • Çalışma süresi: 96 saniye
  • İşlenen veri: 28GB, 53M satır
  • PK tabanlı granule filtreleme ile sürede %50'den fazla azalma

3. PREWHERE eklenmiş

  • Çalışma süresi: 61 saniye
  • İşlenen veri: 16GB
  • İndekslenmemiş filtre koşulları da uygulanarak I/O daha da azaltılır

4. Lazy Materialization etkin

  • Çalışma süresi: 0,18 saniye
  • İşlenen veri: 807MB
  • Sonuçta gereken yalnızca 3 satır, büyük sütunlardan yüklenir

> Toplamda 1.200 kattan fazla performans artışı, 150 kattan fazla bellek kullanımı azalması

Filtresiz Top N sorgularında da etkili

  • Filtre içermeyen tam sıralama sorgusunda:

    SELECT helpful_votes, product_title, review_headline, review_body  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3;

  • lazy materialization öncesi: 219 saniye

  • lazy materialization sonrası: 0,139 saniye

  • 1.576 kat hız artışı, 40 kat daha az I/O, 300 kat daha az bellek kullanımı

Yürütme planını inceleme

EXPLAIN actions = 1  
SELECT helpful_votes, product_title, review_headline, review_body  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3  
SETTINGS query_plan_optimize_lazy_materialization = true;
  • Sonuç:
Lazily read columns: review_headline, review_body, product_title   
  Limit                    
    Sorting                             
      ReadFromMergeTree
  • Büyük sütunlar yalnızca sıralama ve LIMIT sonrasında yüklenir

Sonuç

  • ClickHouse'un I/O optimizasyon yığını tamamlanıyor: Index → PREWHERE → Lazy Materialization
  • Kod değiştirmeden, yalnızca sorgu yürütme biçimiyle performans yüzlerce ila binlerce kat artabiliyor
  • Özellikle Top N deseni, büyük sütunlar ve LIMIT sorguları için ideal
  • Varsayılan olarak etkin olduğundan, kullanıcı ayrıca ayar yapmasa da otomatik uygulanır

> Aynı SQL, aynı makine, farklı sonuç
> Hızlı = daha az okuma = ClickHouse

İlgili okumalar

2 yorum

 
zihado 2025-04-24

> ClickHouse ile StarRocks'u karşılaştıran biri var mı merak ediyorum; birkaç ay önce StarRocks'un join performansı daha iyi görünüyordu
https://d2.naver.com/helloworld/1168674
 
GN⁺ 2025-04-24
Hacker News yorumları

  • Bu optimizasyonun, özellikle istenen sütunlarda büyük değerler bulunabildiğinde, büyük veri kümelerinden rastgele örnekler çıkarırken dramatik hız artışları sağlayacağı düşünülüyor

    • Temel SQL tarifi, örneğe dahil edilecek satırları belirlemek için LIMIT ifadesini kullanıyor
    • Yeni optimizasyon, LIMIT ifadesi veri kümesini az sayıda satıra filtreleyene kadar büyük sütunların okunmasını ertelemeyi vadediyor
    • ClickHouse'ta bu optimizasyonun bu sorguları hızlandırıp hızlandırmadığını doğrulayabilecek biri olup olmadığı merak ediliyor

  • ClickHouse'u gerçekten çok seviyorum

    • Yakın zamanda keşfettim; analiz için verimsiz çözümlerle kıyaslandığında adeta temiz hava gibi geliyor
    • Çok hızlı ve CLI'ını kullanmak da keyifli

  • Kaydırılamayan web sitelerini anlayamıyorum

    • Biraz aşağı kaydırınca yukarı zıplıyor ve kullanılamaz hale geliyor

  • Geç maddeselleştirme, 19 yıl sonra

    • İlgili bağlantı paylaşılmış

  • Yeni maddeselleştirme seçeneğiyle ilgili değil ama şu kısım dikkat çekici

    • Sorgunun 150 milyon değeri sıralayıp ilk 3'ü döndürmesi 70 milisaniye sürüyor
    • Modern donanım ve yazılım karşısında yavaş sorgulara dair zihinsel modeli güncellemek gerekiyor
    • 150 milyon tamsayıyı 70 milisaniyede sıralamak şaşırtıcı değil
    • Tepe bellek kullanımı 3.59 MiB
    • Çok iyi bir makale; net biçimde açıklanmış ve iyi diyagramlar içeriyor

  • ClickHouse'un WSL veya Linux sanal makinesi gerektirmeyen yerel bir Windows sürümü olsaydı, muhtemelen DuckDB'den daha popüler olurdu

    • MySQL'in PostgreSQL'den daha popüler olmasının nedenlerinden biri, MySQL'in bir Windows kurulum programına sahip olmasıydı

  • Havalimanı dramına rağmen sahil tatili planlıyorum

    • Teknik bilgiler ve diyagramlar üst düzeydi, ama hikâye de içerdiği için daha da iyiydi

  • ClickHouse modern mühendisliğin bir başyapıtı

    • Performansa mutlak düzeyde önem veriyor

  • ClickHouse ile StarRocks'u karşılaştıran biri olup olmadığını merak ediyorum

    • Birkaç ay önce StarRocks'un join performansı daha iyi görünüyordu

  • Bu tür veritabanlarının, satır tabanlı tüm veritabanlarının neyi yanlış yaptığını göstermesi şaşırtıcı

    • btree indeks yapısıyla bu hızlara yaklaşmak mümkün değil
    • Modern makinelerin ne kadar hızlı olduğunu görmek şaşırtıcı
    • Veri kümesinin muhtemelen düzgün şekilde sıkıştırılmadığı düşünülüyor
    • Veriyi okumak, sıkıştırmayı açmaktan daha yavaş
    • Cloudflare makalesini hatırlatıyor; şifrelemenin bedava olduğu fikri vardı
    • Hesaplama motoru (chdb) kullanması şaşırtıcı