Database Thực Chiến on Thanh HV's Blog

Bài 6 — Kiến Trúc Thực Tế

Thu, 02 Jul 2026 14:00:00 +0700

Cách đọc: mỗi mục trả lời năm câu hỏi — chọn gì, vì sao, vì sao KHÔNG chọn phương án khác, scale/chi phí dự kiến, và rủi ro chính. Các con số là mức định cỡ (order of magnitude) để lập luận, không phải cam kết hiệu năng.

6.1. E-commerce

Phân rã workload: đơn hàng/thanh toán/tồn kho (transactional, bất biến chặt) · catalog sản phẩm (schema đa dạng, đọc nhiều) · hành vi người dùng + funnel (event, tỷ row) · giỏ hàng/session (nóng, TTL).

Bài 5 — So Sánh PostgreSQL, MongoDB & ClickHouse

Thu, 02 Jul 2026 13:00:00 +0700

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ự:

Bài 4 — ClickHouse

Thu, 02 Jul 2026 12:00:00 +0700

Tiền đề: Chương 1 (columnar vs row, LSM, vectorized execution) và các chương PostgreSQL/MongoDB để đối chiếu. Chủ đề trung tâm của chương: ClickHouse nhanh không phải vì “code giỏi hơn”, mà vì nó từ bỏ một cách có chủ đích những thứ OLAP không cần.

1. Problem Statement

Bài toán: trả lời câu hỏi phân tích (aggregation, group by, filter) trên hàng tỷ đến hàng nghìn tỷ row trong dưới một giây, với dữ liệu mới đến liên tục.

Bài 3 — MongoDB

Thu, 02 Jul 2026 11:00:00 +0700

Tiền đề: Chương 1 (LSM/B+Tree, replication, sharding, CAP/PACELC). Góc nhìn: từ người thiết kế engine — WiredTiger, oplog, Replica Set, sharding — không phải từ tutorial CRUD.

1. Problem Statement

MongoDB giải bài toán gì? Hai bài toán mà RDBMS đầu những năm 2000 giải kém:

Impedance mismatch: đối tượng trong ứng dụng (nested, mảng, đa hình) phải “băm” ra hàng chục bảng chuẩn hóa rồi JOIN lại. Mỗi thay đổi cấu trúc là một cuộc migration. Tốc độ phát triển sản phẩm bị schema ghì lại.
Scale-out: RDBMS thời đó scale ghi bằng cách mua máy to hơn; sharding phải tự chế ở tầng ứng dụng (như Facebook/YouTube từng làm với MySQL — tốn cả đội ngũ chỉ để vận hành sharding).

Nếu không có nó thì sao? Hoặc chịu ma sát schema + tự shard bằng tay, hoặc dùng key-value store thuần (mất khả năng query phong phú). MongoDB đặt cược vào điểm giữa: document model giàu query + sharding tích hợp.

Bài 2 — PostgreSQL

Thu, 02 Jul 2026 10:00:00 +0700

Tiền đề: đã đọc Chương 1 (WAL, MVCC, B+Tree, buffer pool, replication). Góc nhìn: từ vị trí người thiết kế engine, không phải người dùng API.

1. Problem Statement

PostgreSQL giải bài toán gì? Lưu trữ dữ liệu quan hệ với tính đúng đắn tuyệt đối dưới concurrency cao: transaction ACID đầy đủ, constraint được thực thi nghiêm ngặt, SQL chuẩn và giàu tính năng, mở rộng được (extension), trong khi vẫn đủ nhanh cho đại đa số workload OLTP.

Bài 1 — Database Fundamentals

Thu, 02 Jul 2026 09:00:00 +0700

Đối tượng: Software Engineer → Software Architect Mục tiêu: Hiểu bản chất vật lý và logic của mọi database engine, làm nền tảng để hiểu sâu PostgreSQL, MongoDB và ClickHouse ở các chương sau.

1.1. Problem Statement: Vì sao database là bài toán khó?

Về mặt bề ngoài, một database chỉ làm hai việc: ghi dữ liệu xuống và đọc dữ liệu lên. Vậy tại sao nhân loại cần hàng chục năm và hàng trăm engine khác nhau để giải bài toán này?

Bài 0 — Giới Thiệu Series

Thu, 02 Jul 2026 08:00:00 +0700

Database Engineering — từ First Principles đến quyết định kiến trúc production

Dành cho Software Engineer, Backend Engineer, Senior Engineer, Tech Lead, Solution Architect và Software Architect. Viết theo tinh thần Principal Engineer hướng dẫn Senior Engineer: mọi kết luận đều trả lời tại sao, đánh đổi điều gì, và điều gì xảy ra nếu làm ngược lại.

Mục lục

Chương 1 — Database Fundamentals

Nền tảng bắt buộc trước khi đọc các chương sau: Disk vs Memory, Page, Buffer Pool, WAL, Transaction & ACID, Isolation Levels, MVCC, B+Tree vs LSM Tree, Query Execution & Optimizer, Replication, Partitioning vs Sharding, CAP & PACELC, Distributed Systems Fundamentals. Kết chương bằng bản đồ tư duy đối chiếu ba database.