Case Study: Hành trình Momentic chuyển đổi từ PostgreSQL sang ClickHouse để tối ưu hóa hiệu năng và khả năng mở rộng

Giới thiệu

Trong bài viết này, chúng ta sẽ cùng phân tích trường hợp thực tế của Momentic - một công ty cung cấp nền tảng kiểm thử phần mềm dựa trên AI. Họ đã thực hiện một cuộc "đại tu" hệ thống caching (bộ nhớ đệm) để xử lý hơn 2 triệu truy vấn mỗi ngày trên tổng số 20 tỷ mục dữ liệu, duy trì độ trễ trung bình khoảng 250ms. Chìa khóa của sự thành công này nằm ở việc chuyển đổi từ cơ sở dữ liệu quan hệ PostgreSQL sang cơ sở dữ liệu hướng cột ClickHouse.

Momentic: Chuyển đổi từ PostgreSQL sang ClickHouse

Tại sao PostgreSQL không còn đáp ứng được nhu cầu?

Ban đầu, Momentic sử dụng PostgreSQL làm hệ thống lưu trữ cache. Tuy nhiên, khi quy mô dữ liệu tăng trưởng từ 80.000 lên 1 tỷ mục, các hạn chế về hiệu năng bắt đầu bộc lộ rõ rệt:

Tranh chấp tài nguyên: Với workload yêu cầu ghi và đọc cao, hệ thống gặp phải tình trạng tranh chấp khóa (lock contention) khi các truy vấn đọc và ghi thực hiện đồng thời.
Giới hạn của B-tree: Trong PostgreSQL, chi phí truy vấn thường tăng tỉ lệ thuận với kích thước dữ liệu. Khi số lượng mục tăng lên theo cấp số nhân, hiệu năng giảm sút nghiêm trọng.

Tại sao ClickHouse là giải pháp thay thế?

ClickHouse mang lại lợi thế kiến trúc vượt trội nhờ cơ chế sparse primary indexes (chỉ mục chính thưa) thay vì B-tree truyền thống. Điều này cho phép ClickHouse thu hẹp phạm vi tìm kiếm xuống một số lượng nhỏ các "granules" (hạt dữ liệu) khi các giá trị khóa được xác định, giúp tăng tốc độ truy vấn đáng kể ở quy mô lớn.

Thiết kế Primary Key tối ưu

Momentic đã thiết kế lại Primary Key bằng cách kết hợp các trường:

Test ID
Step ID
Phiên bản Momentic
Git branch
Commit timestamp

Cách thiết kế này giúp tối ưu hóa việc tìm kiếm cho 90% các trường hợp (đặc biệt là các feature branches). Tuy nhiên, đối với các nhánh chính (main branches), việc truy vấn có thể quét qua quá nhiều dữ liệu, dẫn đến tình trạng sử dụng bộ nhớ và đĩa cứng tăng đột biến.

Giải pháp cho các truy vấn "nặng": Materialized Views

Để khắc phục tình trạng quét dữ liệu quá lớn trên các nhánh chính, Momentic đã sử dụng Materialized Views để tính toán trước (precompute) các commit timestamp khả dụng cho mỗi Test ID. Điều này cho phép hệ thống truy cập trực tiếp đến phần dữ liệu cần thiết mà không cần quét toàn bộ bảng.

Thay đổi chiến lược truy vấn và loại bỏ Redis

Momentic đã thực hiện một thay đổi quan trọng trong cách tương tác với dữ liệu:

Loại bỏ các truy vấn phức tạp: Thay vì sử dụng 3 truy vấn riêng biệt như trong PostgreSQL, họ chuyển sang sử dụng INSERT kết hợp với ReplacingMergeTree của ClickHouse.
Quy trình xử lý mới:
- SELECT để lấy cache.
- RE-INSERT các cache đã sử dụng để gia hạn TTL (Time-to-Live).
- INSERT các cache mới sau khi chạy kiểm thử.
- Để ClickHouse tự động xử lý việc khử trùng lặp (deduplication) dữ liệu một cách bất đồng bộ.

Kết quả là họ đã loại bỏ hoàn toàn tầng Redis, giúp đơn giản hóa kiến trúc hệ thống mà vẫn đảm bảo hiệu năng cao.

Quy trình di chuyển dữ liệu an toàn

Để đảm bảo không làm gián đoạn hệ thống, Momentic đã thực hiện chiến lược di chuyển từng bước:

Chạy song song: Ghi dữ liệu vào cả hai hệ thống (PostgreSQL và ClickHouse).
Shadow Querying: Traffic sản phẩm vẫn được phục vụ từ PostgreSQL, trong khi ClickHouse chạy các truy vấn "bóng" (shadow queries) để so sánh kết quả giữa hai hệ thống.
Chuyển đổi dần dần: Sau khi xác nhận tính chính xác, traffic được chuyển dần từ PostgreSQL sang ClickHouse.
Duy trì dự phòng: Tiếp tục ghi song song trong một khoảng thời gian sau khi chuyển đổi để đảm bảo khả năng rollback an toàn nếu có sự cố.

Kết luận

Nhờ việc tái cấu trúc kiến trúc dữ liệu, Momentic đã thành công trong việc mở rộng cache lên 20 tỷ mục, xử lý hơn 2 triệu truy vấn mỗi ngày với độ trễ trung bình 250ms. Đây là minh chứng rõ ràng cho việc lựa chọn công cụ phù hợp (ClickHouse) cho các bài toán phân tích và lưu trữ dữ liệu lớn so với các cơ sở dữ liệu quan hệ truyền thống.