Cloudflare phát hiện nút thắt hiệu suất trong giai đoạn lập kế hoạch truy vấn của ClickHouse

Cloudflare gần đây đã mô tả chi tiết cách họ phát hiện và giải quyết vấn đề hiệu suất nghiêm trọng ảnh hưởng đến hệ thống thanh toán của mình. Nguyên nhân gốc rễ được xác định là sự tranh chấp (contention) xảy ra bên trong giai đoạn lập kế hoạch truy vấn của ClickHouse, một cơ sở dữ liệu phân tích mã nguồn mở phổ biến.

Thời gian thực hiện truy vấn trung bình

Quy trình dữ liệu của Cloudflare hỗ trợ các hệ thống thanh toán và phát hiện gian lận, do đó bất kỳ sự chậm trễ nào cũng có thể ảnh hưởng đến nhiều dịch vụ hạ nguồn. Sau một đợt di chuyển dữ liệu làm tăng đáng kể số lượng phần dữ liệu (data parts), các công việc tổng hợp hàng ngày trong ClickHouse trở nên chậm chạp hơn nhiều, mặc dù các chỉ số hiệu suất tiêu chuẩn như I/O, mức sử dụng bộ nhớ và số hàng được quét vẫn trông bình thường.

Cloudflare đã sử dụng ClickHouse từ trước khi hệ thống này hỗ trợ hết hạn dữ liệu tích hợp và quản lý hàng trăm petabyte dữ liệu. Do đó, họ đã xây dựng hệ thống lưu trữ riêng của mình bằng cách chia dữ liệu trong bảng Ready-Analytics thành các phân vùng hàng ngày và xóa mọi dữ liệu cũ hơn 31 ngày. Đến tháng 12 năm 2024, hệ thống này đã phát triển tới hơn 2 PiB dữ liệu với tốc độ nạp dữ liệu hàng triệu hàng mỗi giây.

Trong quá trình di chuyển, Cloudflare đã thay đổi sơ đồ phân vùng của ClickHouse để bao gồm không gian tên của khách hàng, cho phép quản lý thời gian lưu giữ dữ liệu riêng biệt cho từng thuê bao. James Morrison và Christian Endres, các kỹ sư hệ thống phân tán cấp cao của Cloudflare, giải thích vấn đề phát sinh:

"Một lượng lớn thời gian đã được dành cho việc lập kế hoạch truy vấn. Đây là giai đoạn trước khi thực thi, khi ClickHouse quyết định các phần nào cần đọc (...) 45% thời gian CPU mẫu được dành cho một hàm duy nhất gọi là filterPartsByPartition (...) Vấn đề không phải là công việc bị giới hạn bởi CPU; đó là sự tranh chấp khóa khổng lồ. Hơn một nửa thời gian truy vấn của chúng tôi được dành để chờ lấy một mutex duy nhất (MergeTreeData) bảo vệ danh sách các phần của bảng."

Để giảm thiểu sự chậm trễ này, đội ngũ đã áp dụng ba thay đổi chính: vá ClickHouse để thay thế khóa độc quyền (exclusive lock) bằng khóa chia sẻ (shared lock), loại bỏ bản sao danh sách đầy đủ các phần dữ liệu cho mỗi truy vấn, và cải thiện bộ lọc phần dữ liệu để tránh quét toàn bộ danh sách mỗi lần.

Biểu đồ minh họa hiệu suất sau khi vá lỗi

Kết quả là các thay đổi này đã giảm đáng kể độ trễ truy vấn và ổn định hiệu suất khi số lượng phần dữ liệu tiếp tục tăng trưởng. Sau khi triển khai bản vá này vào tháng 3 năm 2026, thời gian truy vấn đã giảm 50%. Quan trọng hơn, điều này đã phá vỡ mối tương quan giữa thời gian truy vấn và số lượng phần dữ liệu.

Edydh Marquez Avila, kỹ sư lĩnh vực tại Park Place Technologies, đã nhận xét trên LinkedIn về bài viết này:

"Cuộc điều tra ClickHouse của Cloudflare là một lời nhắc nhở tốt rằng các lỗi hạ tầng hiện đại ngày càng xảy ra ở các lớp phối hợp, không phải là các giới hạn tài nguyên rõ ràng (...) Tín hiệu thú vị rộng hơn chính ClickHouse (...) Viễn cảnh cấp cao một mình không còn đủ để chẩn đoán các hệ thống quy mô lớn dưới sự đồng thời. Khả năng hiển thị thực thi cấp thấp vẫn rất quan trọng."

Mặc dù các bản vá lỗi đã ổn định hiệu suất truy vấn và giải quyết sự chậm trễ thanh toán ngay lập tức, nhưng thiết kế phân vùng cơ bản vẫn có thể tạo ra các vấn đề vận hành khi số lượng phần dữ liệu tiếp tục tăng. Theo các tác giả, tải siêu dữ liệu ngày càng tăng cũng đã ảnh hưởng đến ZooKeeper, quản lý sự phối hợp của cụm ClickHouse. Đội ngũ đang đặt câu hỏi liệu kiến trúc hiện tại sẽ có thể duy trì bền vững trong dài hạn hay không.

Cloudflare đã đóng góp các thay đổi này cho dự án ClickHouse, nơi chúng đã được hợp nhất vào nguồn chính và có sẵn bắt đầu từ phiên bản 25.11.