ClickHouse ฉลาดขี้เกียจขึ้นและเร็วขึ้น - เปิดตัวการเพิ่มประสิทธิภาพแบบ Lazy Loading

 (clickhouse.com)
6 คะแนน โดย GN⁺ 2025-04-24 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ClickHouse ได้นำเทคนิคการเพิ่มประสิทธิภาพใหม่อย่าง lazy materialization มาใช้ ทำให้ประสิทธิภาพของคิวรี Top N ดีขึ้นได้สูงสุดถึง 1,500 เท่า
  • ลด disk I/O ให้น้อยที่สุดด้วย กลยุทธ์การอ่านข้อมูลคอลัมน์เฉพาะเมื่อจำเป็น
  • ทำงานร่วมกับเทคนิคเดิมอย่าง column storage, index และ PREWHERE เพื่อสร้างสแตกการเพิ่มประสิทธิภาพ I/O แบบเป็นลำดับชั้น
  • โหลดข้อมูลคอลัมน์แบบหน่วงเวลาตามแผนการรันคิวรี โดยมีผลเด่นชัดเป็นพิเศษกับ คิวรีที่มีคำสั่ง LIMIT
  • เปิดใช้งานมาเป็นค่าเริ่มต้น ทำให้ได้ประสิทธิภาพเพิ่มขึ้นโดยไม่ต้องแก้โค้ด

กลยุทธ์การเพิ่มประสิทธิภาพแบบหน่วงเวลาของ ClickHouse: Lazy Materialization

แนวคิดหลัก

  • ClickHouse ดึงประสิทธิภาพสูงสุดด้วยการไม่อ่านข้อมูลที่ไม่จำเป็น
  • lazy materialization คือวิธีการ โหลดข้อมูลคอลัมน์เฉพาะในเวลาที่จำเป็นจริงระหว่างการรันคิวรี
  • ทำงาน แยกอิสระจากเทคนิคการเพิ่มประสิทธิภาพ I/O ที่มีอยู่เดิม และช่วยเสริมประสิทธิภาพซึ่งกันและกัน

เทคโนโลยีการเพิ่มประสิทธิภาพ I/O เดิม

  • ที่เก็บข้อมูลแบบคอลัมน์: อ่านเฉพาะคอลัมน์ที่ต้องใช้
  • Sparse Index / Skipping Index / Projections: อ่านเฉพาะ granule ที่ตรงกับเงื่อนไขการกรอง
  • PREWHERE: กรอง คอลัมน์ที่ไม่ได้อยู่ในดัชนี ได้ตั้งแต่ต้น
  • Query Condition Cache: แคชผลของคิวรีที่รันซ้ำเพื่อหลีกเลี่ยงการประมวลผล granule เดิมซ้ำ

หลักการของ Lazy Materialization

  • หากเทคนิคเดิมเน้น ลด I/O ผ่านการกรอง lazy materialization จะเน้น เลื่อนการอ่านออกไปจนถึงจังหวะที่ต้องคำนวณจริง
  • จะอ่านทันทีเฉพาะคอลัมน์ที่ขั้นตอนถัดไปของคิวรีต้องใช้ และ ส่วนที่เหลือจะอ่านหลัง LIMIT เมื่อจำเป็น
  • โดยเฉพาะใน คิวรี Top N ที่ตรวจดูเพียงบางคอลัมน์ จึง แทบไม่ต้องอ่านคอลัมน์ข้อความขนาดใหญ่เลย

> เป็นการเพิ่มประสิทธิภาพที่ทำได้เพราะการจัดเก็บแบบแยกคอลัมน์ และเป็น แนวทางที่ฐานข้อมูลแบบ row-based ทำไม่ได้

ตัวอย่างจริง: ชุดข้อมูลรีวิว Amazon

  • 150M rows, 70GB แบบไม่บีบอัด, 30GB แบบบีบอัด

  • ตัวอย่างคิวรี Top N:

    SELECT helpful_votes  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3;
    • เวลารัน: 0.07 วินาที
    • ประมวลผลได้เร็วเพราะอ่านเพียงคอลัมน์เดียว

  • ตัวอย่างการอ่านคอลัมน์ข้อความขนาดใหญ่:

    SELECT review_body  
FROM amazon.amazon_reviews  
FORMAT Null;
    • เวลารัน: 176 วินาที
    • แม้เป็นคอลัมน์เดียว แต่มีขนาด 56GB จึงเกิดคอขวดที่ disk I/O

เปรียบเทียบประสิทธิภาพตามชั้นของการเพิ่มประสิทธิภาพ

1. ไม่มีการเพิ่มประสิทธิภาพ (Baseline)

  • เวลารัน: 219 วินาที
  • ปริมาณที่ประมวลผล: 72GB, 150M rows
  • อ่านและเรียงลำดับทุกคอลัมน์ทั้งหมด

2. ใช้ Primary Key Index

  • เวลารัน: 96 วินาที
  • ปริมาณที่ประมวลผล: 28GB, 53M rows
  • ลดเวลาได้มากกว่า 50% ด้วยการกรอง granule ตาม PK

3. เพิ่ม PREWHERE

  • เวลารัน: 61 วินาที
  • ปริมาณที่ประมวลผล: 16GB
  • ลด I/O เพิ่มเติมด้วยการใช้เงื่อนไขกรองบนคอลัมน์ที่ไม่อยู่ในดัชนี

4. เปิดใช้ Lazy Materialization

  • เวลารัน: 0.18 วินาที
  • ปริมาณที่ประมวลผล: 807MB
  • โหลดจากคอลัมน์ขนาดใหญ่เฉพาะ 3 row ที่จำเป็นในท้ายที่สุดเท่านั้น

> โดยรวมประสิทธิภาพดีขึ้นมากกว่า 1,200 เท่า และใช้หน่วยความจำน้อยลงมากกว่า 150 เท่า

ใช้ได้ผลแม้กับคิวรี Top N ที่ไม่มีตัวกรอง

  • ในคิวรีเรียงลำดับทั้งชุดข้อมูลที่ไม่มีตัวกรอง:

    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 เท่า, ลด I/O ลง 40 เท่า, ลดการใช้หน่วยความจำลง 300 เท่า

ตรวจสอบ 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
  • โหลดคอลัมน์ขนาดใหญ่หลังจากการ sort และ LIMIT เท่านั้น

สรุป

  • สแตกการเพิ่มประสิทธิภาพ I/O ของ ClickHouse สมบูรณ์ยิ่งขึ้น: Index → PREWHERE → Lazy Materialization
  • ไม่ต้องแก้โค้ด ก็ เพิ่มประสิทธิภาพได้ตั้งแต่หลักร้อยถึงหลักพันเท่าด้วยวิธีรันคิวรีเพียงอย่างเดียว
  • เหมาะอย่างยิ่งกับ รูปแบบ Top N, คอลัมน์ขนาดใหญ่ และ คิวรีที่มี LIMIT
  • เปิดใช้งานเป็นค่าเริ่มต้น จึงถูกนำไปใช้โดยอัตโนมัติโดยที่ผู้ใช้ไม่ต้องตั้งค่าเอง

> SQL เดิม เครื่องเดิม แต่ผลลัพธ์ต่างออกไป
> เร็วขึ้น = อ่านน้อยลง = ClickHouse

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
zihado 2025-04-24

> สงสัยว่ามีใครเคยเปรียบเทียบ ClickHouse กับ StarRocks ไหม เมื่อไม่กี่เดือนก่อนประสิทธิภาพการ join ของ StarRocks ดูดีกว่า
https://d2.naver.com/helloworld/1168674
 
GN⁺ 2025-04-24
ความคิดเห็นใน Hacker News

  • การปรับแต่งนี้น่าจะช่วยเพิ่มความเร็วได้อย่างมาก โดยเฉพาะเมื่อสุ่มตัวอย่างจากชุดข้อมูลขนาดใหญ่ในกรณีที่คอลัมน์ที่ต้องการอาจมีค่าขนาดใหญ่

    • สูตร SQL พื้นฐานใช้คำสั่ง LIMIT เพื่อกำหนดแถวที่จะรวมอยู่ในตัวอย่าง
    • การปรับแต่งใหม่นี้สัญญาว่าจะเลื่อนการอ่านคอลัมน์ขนาดใหญ่ออกไปจนกว่าคำสั่ง LIMIT จะกรองชุดข้อมูลให้เหลือเพียงไม่กี่แถว
    • อยากรู้ว่ามีใครสามารถตรวจสอบได้หรือไม่ว่าการปรับแต่งนี้ช่วยให้คิวรีลักษณะนี้ใน ClickHouse เร็วขึ้นจริงหรือเปล่า

  • ชอบ ClickHouse มากจริงๆ

    • เพิ่งได้ลองใช้เมื่อไม่นานมานี้ และมันให้ความรู้สึกเหมือนได้สูดอากาศบริสุทธิ์เมื่อเทียบกับโซลูชันที่ไม่มีประสิทธิภาพสำหรับงานวิเคราะห์
    • เร็วมาก และ CLI ก็ใช้งานได้อย่างเพลิดเพลิน

  • ไม่เข้าใจเว็บไซต์ที่เลื่อนไม่ได้

    • พอเลื่อนนิดเดียวก็เด้งกลับขึ้นไปด้านบนจนใช้งานไม่ได้

  • Late materialization หลังผ่านไป 19 ปี

    • มีลิงก์ที่เกี่ยวข้องให้

  • แม้จะไม่เกี่ยวกับตัวเลือก materialization ใหม่ แต่ส่วนนี้สะดุดตามาก

    • คิวรีใช้เวลา 70 มิลลิวินาทีในการจัดเรียงค่า 150 ล้านค่าและส่งคืน 3 อันดับแรก
    • ต้องอัปเดตภาพจำทางความคิดเกี่ยวกับคิวรีที่ช้าบนฮาร์ดแวร์และซอฟต์แวร์ยุคใหม่
    • การจัดเรียงจำนวนเต็ม 150 ล้านตัวภายใน 70 มิลลิวินาทีไม่น่าแปลกใจเลย
    • การใช้หน่วยความจำสูงสุดอยู่ที่ 3.59 MiB
    • เป็นบทความที่ยอดเยี่ยมมาก อธิบายได้ชัดเจนและมีไดอะแกรมที่ดี

  • ถ้า ClickHouse มีรีลีสแบบ Windows native ที่ไม่ต้องพึ่ง WSL หรือ Linux VM มันน่าจะได้รับความนิยมมากกว่า DuckDB

    • หนึ่งในเหตุผลที่ MySQL ได้รับความนิยมมากกว่า PostgreSQL คือ MySQL มีตัวติดตั้งสำหรับ Windows

  • กำลังวางแผนวันหยุดริมทะเลแม้จะมีดราม่าที่สนามบิน

    • ข้อมูลเชิงเทคนิคและไดอะแกรมยอดเยี่ยมมาก แต่การมีเรื่องเล่าประกอบทำให้ยิ่งดีขึ้นไปอีก

  • ClickHouse คือผลงานชิ้นเอกของวิศวกรรมสมัยใหม่

    • ให้ความสำคัญกับประสิทธิภาพอย่างที่สุด

  • อยากรู้ว่ามีใครเคยเปรียบเทียบ ClickHouse กับ StarRocks หรือไม่

    • เมื่อไม่กี่เดือนก่อน ประสิทธิภาพการ join ของ StarRocks ดูดีกว่า

  • น่าทึ่งที่ฐานข้อมูลเหล่านี้แสดงให้เห็นว่าฐานข้อมูลแบบแถวทั้งหมดทำพลาดตรงไหน

    • เป็นไปไม่ได้ที่จะเข้าใกล้ความเร็วระดับนี้ด้วยโครงสร้างดัชนี btree
    • น่าทึ่งที่ได้เห็นว่าเครื่องสมัยใหม่เร็วแค่ไหน
    • ดูเหมือนว่าพวกเขาอาจไม่ได้บีบอัดชุดข้อมูลอย่างเหมาะสม
    • การอ่านข้อมูลช้ากว่าการคลายการบีบอัด
    • ทำให้นึกถึงบทความของ Cloudflare ที่มีแนวคิดว่าการเข้ารหัสนั้นฟรี
    • น่าทึ่งที่ใช้ compute engine (chdb)