Giữ cho hàng đợi Postgres "khỏe mạnh" trong môi trường đa tác vụ

Hệ tiêu hóa khỏe mạnh là hệ thống có khả năng loại bỏ chất thải hiệu quả. Cơ sở dữ liệu (Database) cũng có phần tương tự: nếu bạn muốn một bảng hàng đợi (queue table) hoạt động trơn tru, bạn cần giám sát chặt chẽ các cơ chế dọn dẹp rác trước khi hệ thống bị quá tải.

Postgres đã là lựa chọn phổ biến cho các tác vụ dựa trên hàng đợi từ lâu, và qua nhiều phiên bản, nó ngày càng trở nên mạnh mẽ hơn cho loại workload này. Tuy nhiên, điều gì khiến hàng đợi công việc (job queue) trở nên vấn đề nan giải? Dù công nghệ có tiến bộ, những "cạm bẫy" nào vẫn còn tồn tại và có thể kéo sập cả ứng dụng của bạn?

Chia sẻ tài nguyên trong một database

Triết lý "chỉ cần dùng Postgres" (just use Postgres) đã khiến nhiều người tin rằng mọi tác vụ đều nên nằm trong một database. Đây không hẳn là một ý tưởng tồi, vì Postgres đủ khả năng xử lý đa dạng các yêu cầu nhờ hệ sinh thái extension phong phú. Kết quả là, cùng một lúc, một cụm database có thể phải chạy nhiều loại workload khác nhau: OLTP, OLAP, Time Series, Queue, v.v. Mỗi loại có nhu cầu và ưu tiên riêng, nhưng lại cạnh tranh cùng một nguồn tài nguyên.

Mặc dù có những dịch vụ chuyên dụng cho từng loại workload, nhưng nếu bạn muốn tối ưu hóa việc chúng cùng tồn tại hài hòa trong Postgres, bạn cần hiểu rõ bản chất của chúng.

Bản chất của hàng đợi (Queue Workload)

Điều làm nên sự độc đáo của bảng hàng đợi là phần lớn các dòng dữ liệu (row) ở đó là nhất thời (transient): chúng được chèn vào, đọc một lần, và sau đó bị xóa. Do đó, kích thước bảng thường giữ ổn định trong khi tổng lượng dữ liệu xử lý qua lại cực lớn.

Lợi ích lớn nhất khi dùng Postgres làm job queue là khả năng đồng bộ trạng thái công việc với các logic khác trong database thông qua giao dịch (transaction). Nếu công việc thất bại, toàn bộ giao dịch sẽ rollback.

Tuy nhiên, vấn đề cốt lõi làm suy giảm hàng đợi và database nằm ở chỗ: khi database không thể dọn dẹp (cleanup) nhanh hơn tốc độ tích tụ dữ liệu mới.

Hiệu suất đơn thuần không phải là vấn đề

Postgres hoàn toàn có khả năng xử lý hàng đợi ở quy mô lớn. Vấn đề thực sự thường nằm ở việc giữ cho hàng đợi hòa hợp với các workload khác chạy cùng trên database.

Sức khỏe của bảng hàng đợi phụ thuộc không chỉ vào cấu hình của nó mà còn vào hành vi của mọi giao dịch khác chạy trên cùng instance Postgres đó.

Vấn đề dọn dẹp Dead Tuples

Khi các dòng dữ liệu bị thay đổi hoặc xóa, Postgres sử dụng cơ chế "Điều khiển đồng thời đa phiên bản" (MVCC), cho phép duy trì nhiều phiên bản của cùng một dòng để các giao dịch khác nhau thấy được dữ liệu phù hợp với thời điểm truy vấn của chúng.

Điều này có nghĩa là trong hàng đợi của chúng ta, một dòng dữ liệu bị lệnh DELETE xóa sẽ không bị loại bỏ ngay lập tức. Thay vào đó, nó được đánh dấu để xóa, trở nên vô hình với các giao dịch mới và vẫn nằm trong database cho đến khi được dọn dẹp. Những dòng dữ liệu vô hình này gọi là "dead tuples".

Dead tuples được dọn dẹp bằng quá trình "vacuum". Mặc dù chúng không được trả về trong câu lệnh SELECT, chúng vẫn gây tốn kém chi phí:

• Với sequential scan, executor vẫn phải đọc dead tuples và kiểm tra tính khả kiến trước khi bỏ qua chúng.
• Với index scan — loại mà hàng đợi của chúng ta thường dùng — chi phí còn tinh vi hơn. Chỉ mục B-tree tích lũy các tham chiếu đến dead tuples, buộc quá trình quét phải đi qua các mục không còn khả kiến. Mỗi dead index entry đồng nghĩa với thêm chi phí I/O lãng phí.

Khi Autovacuum trở nên kém hiệu quả

Có một số tình huống phổ biến khiến autovacuum không thể dọn dẹp hiệu quả. Thường gặp nhất là khi các giao dịch đang hoạt động ngăn chặn dead tuples trở nên có thể thu hồi lại. Postgres sẽ không vacuum away bất kỳ dead tuple nào mà có thể vẫn còn nhìn thấy bởi một giao dịch đang hoạt động. Giao dịch cũ nhất này thiết lập một đường ranh giới gọi là "MVCC horizon". Cho đến khi giao dịch đó hoàn tất, mọi dead tuple mới hơn snapshot của nó đều được giữ lại.

Một giao dịch duy nhất chạy trong 2 phút sẽ chặn horizon trong suốt 2 phút đó. Tương tự, nhiều truy vấn phân tích (analytics) nhỏ chồng chéo lên nhau, dù không chạy lâu individually, cũng có thể giữ cho horizon bị "chốt" liên tục. Điều này khiến autovacuum không thể chạy hiệu quả, dẫn đến việc bảng bị "phình to" (bloat) và hiệu suất sụt giảm nghiêm trọng.

Giải pháp: Database Traffic Control

Postgres cung cấp các cấu hình timeout như statement_timeout hay idle_in_transaction_session_timeout, nhưng những công cụ này khá thô sơ. Chúng chỉ nhắm vào thời gian thực thi của một truy vấn đơn lẻ và không thể giới hạn độ đồng thực thi (concurrency) hay chi phí thực thi.

Chúng ta cần một công cụ có thể phân loại các luồng traffic khác nhau, để các workload ưu tiên không bị ảnh hưởng, và điều tiết tốc độ tiêu thụ tài nguyên của các workload thấp hơn.

PlanetScale giới thiệu Database Traffic Control, một phần của tiện ích mở rộng Insights. Tính năng này cho phép kiểm soát chi tiết cách từng truy vấn thực hiện và lượng tài nguyên chúng tiêu thụ. Bằng cách gán một "Resource Budget" cho các truy vấn nhất định (ví dụ: các truy vấn analytics được gắn thẻ action=analytics), ta có thể giới hạn số lượng worker tối đa có thể chạy đồng thời cho loại truy vấn đó.

Khi các truy vấn analytics chậm này bị giới hạn, autovacuum sẽ có nhiều "khe hở" hơn để chạy và dọn dẹp dead tuples ở tốc độ chấp nhận được. Tất nhiên, ứng dụng cần được thiết kế với logic retry để xử lý các truy vấn bị chặn, nhưng hệ quả là tốc độ xử lý công việc sẽ mượt mà hơn và hàng đợi vẫn khỏe mạnh.

Kết luận

Vấn đề dead tuple MVCC trong hàng đợi Postgres không phải là chuyện quá khứ. Postgres hiện đại đã nâng cao ngưỡng chịu đựng, nhưng cơ chế bên dưới vẫn không đổi. Dead tuples tích tụ khi VACUUM không thể dọn dẹp chúng, và điều này xảy ra khi các giao dịch dài hoặc chồng chéo giữ chặt MVCC horizon.

Trong thế giới "chỉ cần dùng Postgres" nơi hàng đợi, phân tích và logic ứng dụng chia sẻ một database, đây không phải là rủi ro lý thuyết mà là điều kiện vận hành bình thường. Giải pháp không nằm ở việc tinh chỉnh autovacuum một cách mù quáng, mà ở việc đảm bảo VACUUM có thể theo kịp bằng cách kiểm soát lưu lượng truy cập của các workload cạnh tranh.