ClickHouse अब और आलसी, और तेज़ हो रहा है - lazy materialization optimization की शुरुआत

• ClickHouse ने नई optimization technique lazy materialization पेश की है, जिससे Top N queries की performance अधिकतम 1,500 गुना तक बेहतर होती है
• ज़रूरत पड़ने पर ही column data पढ़ने की strategy के जरिए disk I/O को न्यूनतम किया जाता है
• मौजूदा column storage, index, PREWHERE techniques के साथ मिलकर यह एक hierarchical I/O optimization stack बनाता है
• query execution plan के अनुसार column data को delayed loading के जरिए पढ़ा जाता है, जिससे खासकर LIMIT clause वाली queries में बड़ा फायदा मिलता है
• default setting में enabled होने के कारण, बिना code बदले performance improvement मिल सकता है

---

ClickHouse की delayed optimization strategy: Lazy Materialization

मुख्य अवधारणा

• ClickHouse अनावश्यक data न पढ़कर performance को अधिकतम करता है
• lazy materialization वह तरीका है जिसमें query execution के दौरान वास्तव में जब ज़रूरत हो तभी column data load किया जाता है
• यह मौजूदा I/O optimization techniques के साथ स्वतंत्र रूप से काम करते हुए, एक-दूसरे को पूरक performance improvement देता है

मौजूदा I/O optimization techniques

• column-based storage: केवल ज़रूरी columns पढ़े जाते हैं
• Sparse Index / Skipping Index / Projections: filtered conditions से मेल खाने वाले granules ही पढ़े जाते हैं
• PREWHERE: non-index columns को जल्दी filter करता है
• Query Condition Cache: repeated queries के results को cache करके एक ही granule को दोबारा process करने से बचाता है

---

Lazy Materialization का सिद्धांत

• जहाँ मौजूदा techniques filtering के जरिए I/O कम करने पर केंद्रित थीं, वहीं lazy materialization computation के समय तक reading को टाल देता है
• query के अगले step को जिन columns की ज़रूरत हो, उन्हें तुरंत पढ़ा जाता है, और बाकी को LIMIT के बाद ज़रूरत पड़ने पर पढ़ा जाता है
• खासकर Top N queries में केवल कुछ columns ही देखने होते हैं, इसलिए बड़े text columns लगभग पढ़ने ही नहीं पड़ते

यह optimization column-independent storage method की वजह से संभव है, और row-based DB में यह approach संभव नहीं है

---

वास्तविक उदाहरण: Amazon review dataset

• 150M rows, 70GB uncompressed, 30GB compressed

• Top N query उदाहरण:

  SELECT helpful_votes  
  FROM amazon.amazon_reviews  
  ORDER BY helpful_votes DESC  
  LIMIT 3;  
  

  • execution time: 0.07 सेकंड
  • केवल column query होने से तेज़ processing

• बड़े text column query का उदाहरण:

  SELECT review_body  
  FROM amazon.amazon_reviews  
  FORMAT Null;  
  

  • execution time: 176 सेकंड
  • एक ही column होने के बावजूद 56GB के कारण disk I/O bottleneck होता है

---

optimization layers लागू होने पर performance comparison

1. कोई optimization नहीं (Baseline)

• execution time: 219 सेकंड
• throughput: 72GB, 150M rows
• सभी columns पढ़कर sort किया जाता है

2. Primary Key Index लागू

• execution time: 96 सेकंड
• throughput: 28GB, 53M rows
• PK-आधारित granule filtering से 50% से अधिक समय की बचत

3. PREWHERE जोड़ा गया

• execution time: 61 सेकंड
• throughput: 16GB
• non-index filter conditions लागू करके अतिरिक्त I/O कम किया गया

4. Lazy Materialization enabled

• execution time: 0.18 सेकंड
• throughput: 807MB
• आख़िर में ज़रूरी केवल 3 rows ही बड़े columns से load की जाती हैं

कुल मिलाकर 1,200 गुना से अधिक performance improvement, और 150 गुना से अधिक memory usage reduction

---

बिना filter वाली Top N queries में भी असरदार

• बिना filter वाली full sort query में:

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

• lazy materialization से पहले: 219 सेकंड

• lazy materialization के बाद: 0.139 सेकंड

• 1,576 गुना speed improvement, 40 गुना I/O reduction, 300 गुना memory usage reduction

---

execution plan की जाँच

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;  

• परिणाम:

Lazily read columns: review_headline, review_body, product_title   
  Limit                    
    Sorting                             
      ReadFromMergeTree  

• sorting और LIMIT के बाद ही बड़े columns load होते हैं

---

निष्कर्ष

• ClickHouse का I/O optimization stack पूरा हुआ: Index → PREWHERE → Lazy Materialization
• code बदले बिना, सिर्फ query execution तरीके से performance सैकड़ों से हज़ारों गुना बेहतर हो सकती है
• खासकर Top N pattern, बड़े columns, और LIMIT queries के लिए आदर्श
• default setting में enabled होने के कारण, user को अलग से configuration करने की ज़रूरत नहीं

वही SQL, वही machine, लेकिन नतीजे अलग
तेज़ = कम पढ़ना = ClickHouse

[zihado]

> सोच रहा हूँ कि क्या किसी ने ClickHouse और StarRocks की तुलना की है; कुछ महीने पहले StarRocks का join performance बेहतर लग रहा था
https://d2.naver.com/helloworld/1168674

[GN⁺]

Hacker News राय

• यह optimization बड़े data set से random sample निकालते समय खास तौर पर नाटकीय speedup दे सकती है, खासकर जब इच्छित column में बड़े values हो सकते हों

  • बुनियादी SQL recipe LIMIT clause का उपयोग करके यह तय करती है कि sample में कौन-सी rows शामिल होंगी
  • नया optimization वादा करता है कि बड़े columns को पढ़ना तब तक टाला जाएगा जब तक LIMIT clause data set को कुछ ही rows तक filter न कर दे
  • जिज्ञासा है कि क्या कोई देख सकता है कि ClickHouse में यह optimization इन queries को तेज करता है या नहीं

• मुझे ClickHouse सच में बहुत पसंद है

  • इसे हाल ही में खोजा, और analytics के लिए inefficient solutions की तुलना में यह ताज़ी हवा के झोंके जैसा लगा
  • यह बेहद तेज है और इसका CLI इस्तेमाल करना भी आनंददायक है

• जो website scroll ही नहीं होने देती, उसे समझना मुश्किल है

  • थोड़ा scroll करते ही ऊपर उछल जाती है, इसलिए इस्तेमाल लायक नहीं रहती

• late materialization, 19 साल बाद

  • संबंधित लिंक साझा किया गया

• नए materialization option से संबंधित नहीं है, लेकिन यह हिस्सा ध्यान खींचने वाला था

  • query 150 million values को sort करके top 3 लौटाती है, और इसमें 70 milliseconds लगते हैं
  • modern hardware और software के संदर्भ में slow query को लेकर अपने mental model को अपडेट करने की ज़रूरत है
  • 150 million integers को 70 milliseconds में sort कर लेना हैरान करने वाली बात नहीं है
  • peak memory usage 3.59 MiB है
  • यह बहुत शानदार लेख है, साफ़ तौर पर समझाया गया है और इसमें अच्छे diagrams हैं

• अगर ClickHouse का Windows native release होता, जिसे WSL या Linux virtual machine की ज़रूरत न पड़ती, तो शायद यह DuckDB से ज्यादा लोकप्रिय होता

  • MySQL के PostgreSQL से ज्यादा लोकप्रिय होने की एक वजह यह थी कि MySQL के पास Windows installer था

• airport drama के बावजूद मैं beach vacation की योजना बना रहा हूँ

  • technical जानकारी और diagrams बेहतरीन थे, लेकिन कहानी शामिल होने से यह और भी अच्छा बन गया

• ClickHouse आधुनिक engineering की एक masterpiece है

  • यह performance पर पूर्ण ध्यान देता है

• जिज्ञासा है कि क्या किसी ने ClickHouse और StarRocks की तुलना की है

  • कुछ महीने पहले StarRocks का join performance बेहतर लगता था

• यह हैरान करने वाला है कि इस तरह के database दिखाते हैं कि सभी row-based databases कहाँ गलत हैं

  • btree index structure के साथ इस तरह की speed के करीब पहुँचना संभव नहीं है
  • यह देखना चौंकाने वाला है कि आधुनिक मशीनें कितनी तेज हैं
  • लगता है data set को ठीक से compress नहीं किया गया होगा
  • data पढ़ना, decompress करने से धीमा है
  • इससे Cloudflare का वह लेख याद आता है जिसमें यह विचार था कि encryption मुफ्त है
  • compute engine (chdb) का उपयोग करना चौंकाने वाला है