Nguyên tắc đọc chương này: ba hệ không cùng hạng cân trên cùng một trục. So sánh đúng nghĩa là ánh xạ workload → điểm mạnh cấu trúc, không phải tìm “database tốt nhất”. Mỗi ô dưới đây là hệ quả của kiến trúc đã phân tích ở Chương 2–4; khi nghi ngờ, quay lại chương tương ứng để xem “vì sao”.
5.1. Bảng so sánh tổng hợp Tiêu chí PostgreSQL MongoDB ClickHouse Data Model Quan hệ (bảng, JOIN, constraint) + JSONB làm van linh hoạt Document (BSON), embed/reference, schema-on-read Bảng phẳng columnar, denormalize có chủ đích, không quan hệ Transaction ACID đầy đủ, Serializable thật, transactional DDL — chuẩn vàng ACID trong 1 document (luôn); đa document từ 4.0 — dùng như ngoại lệ, không hàng ngày Gần như không (atomic theo block insert; không đa statement) — theo thiết kế Query Capability Giàu nhất: SQL đầy đủ, CTE, window, lateral, geo, full-text, vector Giàu theo trục document: CRUD + aggregation pipeline; JOIN yếu SQL analytics rất mạnh (aggregate, window, hàm xấp xỉ); JOIN lớn hạn chế; không tối ưu cho OLTP query Read Performance Point lookup/OLTP xuất sắc (B+Tree + buffer pool); analytics lớn kém Point/one-trục xuất sắc khi có index + đủ RAM; analytics lớn kém Point lookup kém (cấu trúc); scan/aggregate hàng tỷ row: nhanh hơn 2 hệ kia 10–1000× Write Performance Tốt (chục nghìn TPS đơn giản/máy tốt); trần = 1 máy; update-heavy chịu thuế vacuum Tốt + scale-out ghi qua sharding; per-document atomic rẻ Ingest batch cực cao (triệu row/s/node); ghi lẻ tẻ = sự cố; update/delete đắt Analytics Đủ cho báo cáo vừa (parallel query, partition); đuối từ trăm triệu row Aggregation operational tốt; analytical toàn dataset yếu Sinh ra để làm việc này Horizontal Scaling Read replica dễ; sharding không tích hợp (Citus/app-level) Tích hợp, trưởng thành (mongos, balancer, reshard 5.0+) Tích hợp (Distributed table) nhưng thủ công hơn Mongo; Cloud tách compute/storage Compression Khiêm tốn (TOAST cho giá trị lớn; không nén page mặc định) Tốt (block compression WiredTiger, prefix index) Xuất sắc (5–20×, codec chuyên dụng theo cột) Storage Efficiency Trung bình; bloat nếu vacuum không theo kịp Khá; thuế tên field lặp, bù bằng nén Tốt nhất cho analytics; part immutable + TTL/tiered Consistency Mạnh mặc định; single-leader rõ ràng Tunable per-operation (w/readConcern) — mạnh khi cấu hình đúng Eventual giữa replica; đủ cho analytics, không cho nghiệp vụ Availability Cao nhưng failover cần tầng ngoài (Patroni/managed) Cao, failover tự động tích hợp (~10–30s) Cao cho đọc (multi-replica); ghi cần thiết kế ingest chịu lỗi Operational Complexity Thấp–vừa (1 node/RS); vacuum + pooler là hai môn bắt buộc Vừa (replica set dễ); sharded cluster = bậc phức tạp mới Vừa–cao tự quản (Keeper, merge, ingest pipeline); thấp nếu Cloud Cost Rẻ nhất ở quy mô nhỏ–vừa; đắt khi ép làm analytics lớn (máy khủng) Hạ tầng RAM-heavy; Atlas tiện nhưng đắt ở scale Chi phí/TB analytics thấp nhất (nén + máy thường); tốn đầu tư ingest Learning Curve SQL phổ cập; nội tạng (vacuum, planner) cần thời gian Bắt đầu dễ nhất; modeling ĐÚNG khó hơn vẻ ngoài nhiều SQL quen; tư duy OLAP (batch, ORDER BY key, denormalize) phải học lại Best Use Cases Hệ giao dịch, tiền, tồn kho, SaaS core, dữ liệu quan hệ bất kỳ Catalog/profile/content đa dạng schema, IoT theo thiết bị, scale-out một-trục Event/log/metric/clickstream, dashboard real-time, time-series lớn Worst Use Cases Analytics tỷ row; write scale-out; queue tần suất cực cao Quan hệ chặt + bất biến phức tạp; BI toàn dataset OLTP bất kỳ; dữ liệu nhỏ; update thường xuyên 5.2. Ba trục phân tích sâu Trục 1 — Mô hình dữ liệu quyết định 80% quyết định Ba câu hỏi theo thứ tự:
...