#postgresql

200 bài viết
DevOps 01/09/2026 9 phút

PostgreSQL trong Kubernetes chạy 10.366 tps và khởi động lại trong 0,3 giây — nhưng cordon đúng một node là pod Pending vĩnh viễn, vì dữ liệu không đi theo được

Dựng PostgreSQL bằng StatefulSet, đo phần chạy tốt rồi đo đúng chỗ nó gãy. Phần tốt: 10.366 tps, dừng sạch trong 13 ms, khởi động lại 0,3 giây, giữ nguyên định danh và volume. Phần không sửa được bằng YAML: PersistentVolume ghim vào một node, cordon node đó là pod Pending mãi mãi vì dữ liệu nằm trên đĩa node đó. Kubernetes dựng lại pod giỏi, nhưng chỉ ở nơi có dữ liệu — và nó không biết cái nào là bản chính.

#kubernetes#postgresql#devops#zero-to-hero
15
Backend 01/09/2026 8 phút

Redis nhanh hơn PostgreSQL 4,1 lần khi ghi — không phải 100 lần như lời đồn; và phần lớn khoảng cách đó là độ bền bị bỏ, không phải kiến trúc

Mở đầu sê-ri bốn mươi phần về Redis, không bằng lời quảng cáo mà bằng cách đo nó cạnh PostgreSQL trên đúng cùng một bài toán. Redis nhanh hơn 4,1 lần khi ghi và 2,0 lần khi đọc — nhưng bật cờ UNLOGGED trên Postgres là khoảng cách co còn 1,4 lần, cho thấy Redis nhanh chủ yếu vì mặc định không hứa gì về độ bền. Bộ nhớ mỗi bản ghi gần bằng nhau (185 vs 178 byte), và có một câu hỏi Redis không trả lời được.

#hieu-nang#postgresql#zero-to-hero#redis
17
Backend 01/09/2026 8 phút

Thêm một dòng CREATE INDEX làm truy vấn nhanh hơn 181 lần — tốt hơn cả tỉ lệ trúng cache 99%, và không thêm một hệ thống nào để hỏng

Cache-aside là mẫu dùng Redis phổ biến nhất, nhưng đo thật cho thấy nó thắng ít hơn ta tưởng. Tra khoá chính: Redis GET 0,062 ms ngang PostgreSQL 0,065 ms — đặt cache ở đây chỉ thêm một chỗ để hỏng. Truy vấn đắt 19,9 ms: cache nhanh hơn 321 lần, nhưng một CREATE INDEX kéo nó xuống 0,110 ms — nhanh hơn 181 lần, tốt hơn cả cache trúng 99%. Bộ đệm che một truy vấn chậm; chỉ mục xoá nó.

#hieu-nang#postgresql#zero-to-hero#redis
16
Backend 01/09/2026 7 phút

200 khách cùng gặp một khoá Redis vừa hết hạn tạo ra đúng 200 truy vấn xuống cơ sở dữ liệu — và một dòng khoá kéo nó về 1, còn làm chính người dùng nhanh hơn 6,4 lần

Cache-aside chạy tốt khi mọi thứ bình thường. Bài này đo đúng khoảnh khắc nó không bình thường: một khoá nóng hết hạn và 200 khách cùng lao vào. Không bảo vệ: 200 truy vấn, p50 vọt lên 360 ms. Một khoá độc quyền: 1 truy vấn, p50 xuống 56 ms — nhanh hơn 6,4 lần, vì CSDL không bị 200 mũi cùng đâm. Trả giá trị cũ: không ai phải chờ, p50 chỉ 29 ms.

#hieu-nang#postgresql#zero-to-hero#redis
14
Backend 01/09/2026 9 phút

Ghi giá trị mới thẳng vào cache lệch với cơ sở dữ liệu 103 trên 120 lần — còn 'xoá cache trước khi cập nhật', cái nghe an toàn nhất, để lại dữ liệu cũ nằm đó vĩnh viễn

Bộ đệm chỉ có ích khi nó đúng. Đo bốn cách giữ nó khớp với cơ sở dữ liệu khi có 8 luồng vừa đọc vừa ghi: ghi đè giá trị mới lệch 103/120 lần (tệ nhất, lại trực giác nhất); xoá-trước-cập-nhật nhìn hoàn hảo cho tới khi thêm người đọc song song thì để lại dữ liệu cũ VĨNH VIỄN; chỉ 'xoá sau khi cập nhật' cho lệch tạm thời tự khỏi. Bài toán thật không phải 'làm sao luôn khớp' mà 'lệch bao lâu thì chấp nhận được'.

#postgresql#zero-to-hero#redis
21
Backend 01/09/2026 9 phút

Gom nhóm bốn trạng thái đơn hàng mất 203,8 ms trong Redis và 8,9 ms trong PostgreSQL — và 203,8 ms đó đóng băng toàn bộ máy chủ Redis

Dựng thử một ứng dụng thật trên Redis rồi đo. Tra một khoá đã biết: Redis thắng, 0,145 ms so với 0,334. Nhưng gom nhóm, lọc, sắp xếp thì nó thua 5–23 lần hoặc không làm được — và mỗi báo cáo chạy trong Lua khiến mọi khách khác chờ một phần năm giây. Redis giỏi tra theo nhãn, dở tra theo thuộc tính; ép nó làm việc thứ hai là tự dựng chỉ mục mà không ai giữ đồng bộ.

#postgresql#zero-to-hero#redis
17