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

• 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

[zihado]

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⁺]

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ı