Một broker Kafka thật ra khởi động 2 giây, chiếm 290 MB — nhẹ hơn hẳn tiếng tăm của nó. Nhưng thứ khiến tôi dừng lại là một cái bẫy đo lường: công cụ dòng lệnh tốn 0,86 giây trong khi gửi tin thật chỉ mất 0,89 mili giây. Chênh nhau một nghìn lần, và rất nhiều người đo trúng cái sai.
Sáu mươi phần, mỗi phần một phép đo, gom lại thành một câu SQL chạy được và một bản tổng kết. Cả năm con số ấn tượng nhất, bốn lời khuyên phổ biến mà phép đo bác bỏ, và ba bài học về cách đo rút ra từ chính những lần tôi đo sai.
Ai cũng bảo gộp lô là 'đổi độ trễ lấy thông lượng'. Tôi đo thì thấy nó làm độ trễ giảm 1.567 lần, cùng lúc với thông lượng. Còn nén trên dữ liệu ngẫu nhiên lại cho ra tệp to hơn bản không nén — và đó chính là cái bẫy suýt khiến tôi kết luận ngược.
Nâng cấp phiên bản lớn là việc mỗi năm làm một lần nên chẳng ai thuộc. Tôi chạy pg_upgrade thật từ PostgreSQL 16 lên 17, đo từng bước — và tìm ra thứ nó mang theo đầy đủ lẫn thứ nó lặng lẽ để lại, đủ khiến máy chủ vừa nâng xong chậm bất thường vài giờ đầu.
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.
'Tỉ lệ trúng đệm phải trên 99%' là một trong những lời khuyên được lặp nhiều nhất về PostgreSQL. Tôi đo xem nó thật sự nói lên điều gì: 19.184 trang bị đánh dấu 'read' chỉ tốn 27,75 ms — 1,4 micro giây mỗi trang, tức tốc độ bộ nhớ, vì có một lớp đệm mà con số đó không nhìn thấy.