Tôi dựng cả Kafka lẫn RabbitMQ trên cùng một máy, ném 200.000 tin vào mỗi bên và đo. Kafka thắng rõ về tốc độ. Nhưng khác biệt quyết định lựa chọn lại nằm ở chỗ khác hẳn: với RabbitMQ đọc xong là tin biến mất, với Kafka đọc xong tin vẫn còn — và đó là khác biệt kiến trúc, không phải hiệu năng.
Bốn mươi phần, mỗi phần một phép đo thật trong container. Bài cuối gom lại những con số đáng mang theo, một bộ cấu hình mặc định mà mọi dòng đều có gốc từ một phép đo, sáu kiểu hỏng im lặng, và bài học đắt nhất: kết quả quá gọn gàng không phải phát hiện — nó là dấu hiệu phép đo đã hỏng.
Window function giải lớp bài toán GROUP BY không giải nổi: xếp hạng trong nhóm, so với dòng trước, cộng dồn. Tôi đo chi phí thật của chúng, so với LATERAL và với cách kéo dữ liệu về ứng dụng tự tính — và bất ngờ là LATERAL nhanh gần gấp đôi window function.
GROUP BY dễ viết nhất mà khó đoán chi phí nhất. Tôi đo lượng bộ nhớ nó thật sự dùng và tìm ra: chi phí phụ thuộc số nhóm đầu ra chứ không phải số dòng đầu vào, cho thêm bộ nhớ gần như vô ích, và một chỉ mục cho 2× tốc độ với 0 bộ nhớ.
LIMIT 20 OFFSET 1000 là cách phân trang ai cũng viết đầu tiên: đúng, ngắn, và chậm dần theo số trang — nhưng chậm bao nhiêu thì ít ai đo. Tôi đo, và đo cả một lỗi nghiêm trọng hơn chuyện chậm: OFFSET neo vào vị trí, mà vị trí thì đổi khi dữ liệu đổi.
JSONB rất tiện: không cần ALTER TABLE, thêm trường lúc nào cũng được. Tôi dựng hai bảng cùng dữ liệu — một cột thường, một JSONB — để đo cái giá của sự tiện đó, và tìm ra ranh giới rõ ràng giữa lúc nên dùng và lúc phải trả giá đắt.