ClickHouse trở nên “lười” hơn và nhanh hơn - giới thiệu tối ưu hóa tải trễ

 (clickhouse.com)
6 điểm bởi GN⁺ 2025-04-24 | 2 bình luận | Chia sẻ qua WhatsApp
  • ClickHouse đã giới thiệu kỹ thuật tối ưu hóa mới lazy materialization, giúp cải thiện hiệu năng truy vấn Top N lên tới 1.500 lần
  • Chiến lược chỉ đọc dữ liệu cột khi cần giúp giảm thiểu đĩa I/O
  • Kết hợp với các kỹ thuật hiện có như lưu trữ dạng cột, index, PREWHERE để tạo thành một stack tối ưu hóa I/O theo tầng
  • Tải dữ liệu cột theo cách trì hoãn dựa trên execution plan của truy vấn, đặc biệt hiệu quả với các truy vấn có mệnh đề LIMIT
  • Được bật theo mặc định, nên có thể tăng hiệu năng mà không cần thay đổi mã nguồn

Chiến lược tối ưu hóa trì hoãn của ClickHouse: Lazy Materialization

Khái niệm cốt lõi

  • ClickHouse tối đa hóa hiệu năng bằng cách không đọc dữ liệu không cần thiết
  • lazy materialization là cách chỉ tải dữ liệu cột vào đúng thời điểm thực sự cần trong quá trình thực thi truy vấn
  • Hoạt động độc lập với các kỹ thuật tối ưu I/O hiện có nhưng mang lại hiệu quả bổ sung cho nhau

Các kỹ thuật tối ưu I/O hiện có

  • Lưu trữ dạng cột: chỉ đọc những cột cần thiết
  • Sparse Index / Skipping Index / Projections: chỉ đọc các granule khớp với điều kiện lọc
  • PREWHERE: lọc sớm với các cột không được index
  • Query Condition Cache: cache kết quả của các truy vấn lặp lại để tránh xử lý lại cùng một granule

Nguyên lý của Lazy Materialization

  • Nếu các kỹ thuật trước đây tập trung vào giảm I/O thông qua lọc, thì lazy materialization trì hoãn việc đọc cho đến thời điểm tính toán thực sự cần
  • Chỉ những cột cần cho bước tiếp theo của truy vấn mới được đọc ngay, còn phần còn lại sẽ được đọc sau LIMIT nếu cần
  • Đặc biệt với truy vấn Top N, vì chỉ cần truy xuất một phần cột nên gần như không phải đọc các cột văn bản dung lượng lớn

> Đây là tối ưu hóa khả thi nhờ cách lưu trữ độc lập theo cột, và là cách tiếp cận không thể thực hiện trong DB dạng row-based

Ví dụ thực tế: bộ dữ liệu đánh giá Amazon

  • 150M rows, 70GB chưa nén, 30GB đã nén

  • Ví dụ truy vấn Top N:

    SELECT helpful_votes  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3;
    • Thời gian thực thi: 0,07 giây
    • Xử lý rất nhanh khi chỉ truy vấn một cột

  • Ví dụ truy vấn cột văn bản dung lượng lớn:

    SELECT review_body  
FROM amazon.amazon_reviews  
FORMAT Null;
    • Thời gian thực thi: 176 giây
    • Chỉ một cột nhưng do dung lượng 56GB nên phát sinh nghẽn cổ chai ở đĩa I/O

So sánh hiệu năng theo từng lớp tối ưu hóa

1. Không tối ưu hóa (Baseline)

  • Thời gian thực thi: 219 giây
  • Lượng xử lý: 72GB, 150M rows
  • Đọc toàn bộ các cột rồi sắp xếp

2. Áp dụng Primary Key Index

  • Thời gian thực thi: 96 giây
  • Lượng xử lý: 28GB, 53M rows
  • Lọc granule theo PK giúp giảm hơn 50% thời gian

3. Thêm PREWHERE

  • Thời gian thực thi: 61 giây
  • Lượng xử lý: 16GB
  • Tiếp tục giảm I/O bằng cách áp dụng cả điều kiện lọc trên cột không có index

4. Bật Lazy Materialization

  • Thời gian thực thi: 0,18 giây
  • Lượng xử lý: 807MB
  • Cuối cùng chỉ tải 3 row cần thiết từ các cột lớn

> Tổng cộng cải thiện hiệu năng hơn 1.200 lần, giảm sử dụng bộ nhớ hơn 150 lần

Vẫn hiệu quả với truy vấn Top N không có bộ lọc

  • Với truy vấn sắp xếp toàn bộ không có bộ lọc:

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

  • Trước lazy materialization: 219 giây

  • Sau lazy materialization: 0,139 giây

  • Tăng tốc 1.576 lần, giảm I/O 40 lần, giảm sử dụng bộ nhớ 300 lần

Kiểm tra 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;
  • Kết quả:
Lazily read columns: review_headline, review_body, product_title   
  Limit                    
    Sorting                             
      ReadFromMergeTree
  • Chỉ tải các cột dung lượng lớn sau khi sắp xếp và LIMIT

Kết luận

  • Hoàn thiện stack tối ưu hóa I/O của ClickHouse: Index → PREWHERE → Lazy Materialization
  • Không cần thay đổi mã nguồn, chỉ nhờ cách thực thi truy vấn mà hiệu năng tăng từ hàng trăm đến hàng nghìn lần
  • Đặc biệt lý tưởng cho mẫu Top N, cột dung lượng lớn, truy vấn LIMIT
  • Được bật theo mặc định nên người dùng không cần cấu hình riêng mà vẫn được áp dụng tự động

> Cùng một SQL, cùng một máy, kết quả khác biệt
> Nhanh hơn = đọc ít hơn = ClickHouse

Bài viết liên quan

2 bình luận

 
zihado 2025-04-24

> Không rõ có ai từng so sánh ClickHouse với StarRocks chưa, vài tháng trước hiệu năng join của StarRocks có vẻ tốt hơn
https://d2.naver.com/helloworld/1168674
 
GN⁺ 2025-04-24
Ý kiến trên Hacker News

  • Tối ưu hóa này có thể mang lại cải thiện tốc độ đáng kể khi lấy mẫu ngẫu nhiên từ các tập dữ liệu lớn, đặc biệt khi các cột được quan tâm có thể chứa giá trị lớn

    • Công thức SQL cơ bản dùng mệnh đề LIMIT để xác định các hàng sẽ được đưa vào mẫu
    • Tối ưu hóa mới hứa hẹn sẽ trì hoãn việc đọc các cột lớn cho đến khi mệnh đề LIMIT lọc tập dữ liệu xuống chỉ còn một số ít hàng
    • Không biết có ai có thể kiểm tra xem tối ưu hóa này trong ClickHouse có thực sự tăng tốc các truy vấn như vậy hay không

  • Tôi thực sự rất thích ClickHouse

    • Mới phát hiện ra nó gần đây, và nó mang lại cảm giác như một luồng gió mới so với các giải pháp kém hiệu quả cho phân tích
    • Rất nhanh và CLI cũng rất dễ dùng

  • Tôi không thể hiểu nổi các website không cho cuộn

    • Chỉ cần cuộn một chút là nó bật ngược lên trên, khiến không thể sử dụng được

  • Trì hoãn materialization, sau 19 năm

    • Có kèm liên kết liên quan

  • Không liên quan đến tùy chọn materialization mới, nhưng đoạn này nổi bật

    • Truy vấn sắp xếp 150 triệu giá trị và trả về 3 giá trị đứng đầu chỉ mất 70 mili giây
    • Cần cập nhật mô hình tư duy của mình về truy vấn chậm trên phần cứng và phần mềm hiện đại
    • Việc sắp xếp 150 triệu số nguyên trong 70 mili giây không còn là điều đáng ngạc nhiên
    • Mức sử dụng bộ nhớ đỉnh là 3.59 MiB
    • Bài viết rất xuất sắc, giải thích rõ ràng và có các sơ đồ tốt

  • Nếu ClickHouse có bản phát hành native cho Windows mà không cần WSL hay máy ảo Linux, có lẽ nó đã phổ biến hơn DuckDB

    • Một trong những lý do MySQL phổ biến hơn PostgreSQL là vì MySQL có trình cài đặt cho Windows

  • Dù có cả màn kịch ở sân bay, tôi vẫn đang lên kế hoạch cho một kỳ nghỉ biển

    • Thông tin kỹ thuật và sơ đồ đều ở mức xuất sắc, nhưng có thêm câu chuyện nên càng hay hơn

  • ClickHouse là một kiệt tác của kỹ thuật hiện đại

    • Sự chú ý tuyệt đối đến hiệu năng

  • Không biết đã có ai so sánh ClickHouse với StarRocks chưa

    • Vài tháng trước, hiệu năng join của StarRocks có vẻ tốt hơn

  • Thật đáng kinh ngạc khi các cơ sở dữ liệu này cho thấy mọi cơ sở dữ liệu hướng hàng đều đang làm sai

    • Không thể đạt đến tốc độ này với cấu trúc chỉ mục btree
    • Thật ấn tượng khi thấy máy móc hiện đại nhanh đến mức nào
    • Có lẽ tập dữ liệu thậm chí còn chưa được nén đúng cách
    • Việc đọc dữ liệu còn chậm hơn giải nén
    • Gợi nhớ đến bài viết của Cloudflare với ý tưởng rằng mã hóa là miễn phí
    • Thật đáng ngạc nhiên khi họ dùng compute engine (chdb)