Database là gì? So sánh dễ hiểu với Excel
Database là Excel siêu mạnh — có khoá, có người canh, hàng triệu người dùng cùng lúc không sợ ghi đè, tìm 1 dòng trong 500 triệu dòng dưới 100ms. Hiểu khi nào cần DB, khi nào Excel đủ.
Mục lục bài viết(12)
Một sơ đồ ER (Entity-Relationship) minh hoạ cấu trúc database — mỗi hình chữ nhật là một bảng (player, item, guild, quest), các đường nối là quan hệ giữa các bảng (player có nhiều item, player thuộc một guild). Đây là "bản đồ" mà mọi dev backend đều vẽ trước khi code. Nguồn: Wikimedia Commons (CC BY-SA 3.0).
Hiểu đơn giản nhất
Database (cơ sở dữ liệu) là Excel siêu mạnh với 5 điểm khác biệt:
- Có khoá an toàn. Không phải ai cũng vào được — phải có user/password và phân quyền chi tiết.
- Có người canh giữ (gọi là DBMS — Database Management System) quyết định ai đọc được, ai sửa được, ai cấm.
- Nhiều người dùng cùng lúc không ghi đè nhau. Excel mở chung chỉ 1 người sửa được. Database cho phép hàng nghìn người ghi cùng lúc mà không loạn.
- Lưu được hàng triệu, hàng tỷ dòng và truy vấn vẫn nhanh dưới 100ms — nhờ index (chỉ mục để tìm nhanh, như mục lục sách).
- Tự backup mỗi đêm, có log đầy đủ "ai đã sửa gì lúc mấy giờ".
Mọi app, web có user đăng nhập, có đơn hàng, có nội dung do user tạo — đều bắt buộc dùng database.
Tại sao bạn cần biết
- Hiểu giá khi mua dịch vụ. Landing page không có DB: 5-15 triệu. Web có user + đơn hàng + DB: 30-80 triệu trở lên. Chênh lệch chính là công sức build DB.
- Phân biệt khi nào Google Sheets đủ, khi nào cần DB thật. Quản 100 khách hàng — Sheets OK. Quản 10.000 khách + 50 nhân viên cùng cập nhật — bắt buộc DB.
- Tránh fail nghiêm trọng khi scale. Nhiều SME khởi đầu lưu khách hàng trong Excel, đến lúc có 5.000 đơn/tháng thì Excel treo, mất data — chuyển sang DB lúc đó tốn gấp 10 lần làm từ đầu.
- Hiểu thuật ngữ dev. "DB lock", "deadlock", "migration" (chuyển đổi schema database), "schema" (cấu trúc bảng database), "index", "query" (truy vấn database) "slow" — biết để nói chuyện được khi dev báo cáo vấn đề.
So sánh nhanh: Excel vs Database
| Tiêu chí | Excel / Google Sheets | Database |
|---|---|---|
| Số dòng tối đa | 1.048.576 (Excel) / 10M (Sheets) | Hàng tỷ, không giới hạn thực tế |
| Số người ghi cùng lúc | 1 (Excel) / vài chục (Sheets) | Hàng nghìn → hàng triệu |
| Tốc độ tìm trên 1 triệu dòng | 30-60 giây | < 100ms (nhờ index) |
| Phân quyền | Sheet-level, đơn giản | Row-level, column-level, chi tiết |
| Backup tự động | Có (Sheets) / không (Excel) | Có, schedule được |
| Transaction (ACID — 4 đảm bảo của database) | Không | Có |
| API truy cập từ code | Có nhưng khó | Tiêu chuẩn, mọi ngôn ngữ |
| Giá | 0-300k/tháng | Từ 0$ (self-host) đến hàng triệu/tháng (cloud) |
| Phù hợp data lượng | < 50k dòng | 50k → hàng tỷ dòng |
| Học khó dễ | Dễ | Trung bình (cần học SQL hoặc API) |
Phân loại Database

Các mô hình database chính: Hierarchical (cây), Network (mạng), Relational (bảng — SQL phổ biến nhất), Object-Oriented và Document (NoSQL). Phần lớn dự án hiện nay chọn Relational (PostgreSQL/MySQL) hoặc Document (MongoDB). Nguồn: Wikimedia Commons (CC BY-SA 3.0).
Có 3 loại chính tuỳ mục đích:
1. SQL — kiểu bảng, kỷ luật (phổ biến nhất)
Database SQL lưu data dạng bảng — giống Excel có nhiều sheet, mỗi sheet là một bảng (users, orders, products), các sheet có quan hệ với nhau.
- Phần mềm: PostgreSQL (mạnh nhất, free), MySQL (phổ biến), SQLite (nhỏ gọn), Microsoft SQL Server (doanh nghiệp)
- Schema cố định: mỗi bảng phải định nghĩa trước có cột nào, kiểu gì (
emaillà text,agelà số,created_atlà datetime) - Dùng SQL (Structured Query Language) — ngôn ngữ chuẩn từ thập niên 1970
- Phù hợp: mọi app có data liên hệ chặt (đơn hàng — khách — sản phẩm — kho)
Ví dụ câu lệnh SQL lấy 20 sản phẩm rẻ nhất trong danh mục thời trang:
SELECT name, price, image_url FROM products
WHERE category = 'fashion' AND price < 500000
ORDER BY price ASC
LIMIT 20;2. NoSQL — kiểu document, linh hoạt
NoSQL lưu data dạng JSON (định dạng trao đổi data phổ biến) document — mỗi document có thể có cấu trúc khác nhau, không bắt buộc theo schema.
- Phần mềm: MongoDB (phổ biến nhất), Firebase Firestore (Google), DynamoDB (AWS)
- Schema linh hoạt: một document user có thể có field
phone, document khác không có - Không dùng SQL chuẩn — mỗi DB có API riêng
- Phù hợp: activity log, content có cấu trúc thay đổi nhiều (game, IoT), prototype nhanh
3. Key-Value — cache siêu nhanh
Lưu cặp key → value trong RAM. Không phải nơi lưu chính, dùng để tăng tốc.
- Phần mềm: Redis (phổ biến nhất), Memcached
- Tốc độ: đọc/ghi < 1ms — nhanh gấp 50-100 lần SQL
- Không bền: mất điện → mất data (trừ khi config persist)
- Phù hợp: cache (lưu kết quả query đắt), session login, hàng đợi (queue), counter (lượt xem)
Một app SaaS (Software as a Service — phần mềm dạng dịch vụ) thực tế thường dùng cả 3: PostgreSQL (data chính) + Redis (cache — bộ đệm lưu tạm để tăng tốc — + session — phiên đăng nhập) + S3 (lưu file ảnh/video) — phân chia tự nhiên theo kiểu data.
Ví dụ thực tế: dữ liệu của bạn ở Shopee
Khi bạn mở app Shopee và xem một sản phẩm, dữ liệu được lưu trong nhiều bảng database. Đây là ước tính cấu trúc và quy mô:
| Bảng | Nội dung | Số dòng ước tính | Loại DB |
|---|---|---|---|
users | Thông tin tài khoản | 200M+ | PostgreSQL |
products | Thông tin sản phẩm | 1B+ | PostgreSQL |
categories | Danh mục (1000 nhánh) | ~1.000 | PostgreSQL |
orders | Đơn hàng đã đặt | 10B+ | PostgreSQL (sharded) |
reviews | Đánh giá sản phẩm | 5B+ | PostgreSQL |
cart | Giỏ hàng tạm thời | 50M (active) | Redis (cache) |
chat_messages | Tin nhắn shop-khách | 100B+ | NoSQL (Cassandra) |
product_views | Lượt xem mỗi sản phẩm | 1T+ events | ClickHouse |
Khi bạn lọc "Áo thun nam dưới 200k, xếp theo đánh giá", app gọi API tới backend, backend chạy truy vấn:
SELECT p.id, p.name, p.price, p.image, AVG(r.rating) as rating
FROM products p
LEFT JOIN reviews r ON p.id = r.product_id
WHERE p.category_id = 312
AND p.price < 200000
AND p.gender = 'male'
GROUP BY p.id
ORDER BY rating DESC
LIMIT 20;Truy vấn này quét trên 1 tỷ dòng products + 5 tỷ dòng reviews, ghép lại, sắp xếp, trả về 20 sản phẩm — trong khoảng 80-150ms. Nếu lưu trong Excel: không bao giờ chạy nổi.
Bí mật của tốc độ:
- Index trên category_id, price, gender — DB chỉ scan vùng nhỏ liên quan (~10M dòng thay vì 1B)
- Cache Redis giữ kết quả của các truy vấn phổ biến (top 20 áo thun nam < 200k) trong 5 phút → 90% người dùng nhận kết quả từ cache trong 5ms
- Sharding — bảng
ordersđược chia thành 100 mảnh trên 100 server khác nhau, mỗi server chỉ giữ 100M dòng

Một kết quả truy vấn SQL điển hình — kết hợp dữ liệu từ nhiều bảng (khách hàng + đơn thuê phim) và trả về dạng bảng. Cấu trúc tabular này quen với người dùng Excel, nhưng đằng sau là engine có thể xử lý hàng tỷ dòng và nhiều người ghi cùng lúc. Nguồn: Wikimedia Commons (CC BY-SA 3.0).
Cái gì có thể sai
| Lỗi | Nguyên nhân | Hậu quả | Cách phòng |
|---|---|---|---|
| Database hết dung lượng | Lưu quá nhiều mà không dọn | Web không đặt được đơn mới | Monitor dung lượng, nâng gói trước khi đầy |
| Backup không hoạt động | Cấu hình sai, bị tắt | Mất hết data khi server cháy | Test restore backup mỗi tháng |
| SQL injection | Code backend ghép chuỗi SQL trực tiếp từ input user | Hacker đọc/xoá được toàn bộ DB | Dùng prepared statement (mọi framework đều có) |
| Migration sai | Đổi schema không cẩn thận | Mất cột, mất dữ liệu | Test migration trên staging trước, có rollback |
| Lock chờ quá lâu | Nhiều transaction tranh giành cùng row | Web treo 30s+ rồi báo lỗi | Index đúng, transaction ngắn, tránh long-running query |
| Slow query | Thiếu index, query phức tạp | TTFB 5-10s, UX tệ | Phân tích EXPLAIN, thêm index, refactor query |
Khi nào dùng gì
| Tình huống | Lưu trong gì |
|---|---|
| Danh sách 50 contact cá nhân | Excel hoặc Google Sheets |
| Quản lý 500 khách của SME | Google Sheets hoặc Airtable |
| Web bán hàng có giỏ + đơn | PostgreSQL hoặc MySQL |
| App có chat realtime | PostgreSQL + Redis (cache) hoặc Firestore |
| SaaS đa người dùng | PostgreSQL + Redis |
| Game / IoT / activity log | MongoDB hoặc Cassandra |
| Cache + session login | Redis |
| File ảnh / video upload | S3 (không phải DB — object storage) |
| Phân tích Big Data | ClickHouse, BigQuery, Snowflake |
Tóm tắt 1 dòng
Database = Excel có khoá, có người canh, có nhiều người dùng cùng lúc, có tốc độ tìm trên hàng tỷ dòng. Mọi app có data của user đều dùng DB. PostgreSQL là lựa chọn mặc định cho 80% dự án.
Đọc tiếp
- Frontend vs Backend khác nhau ở đâu — backend là phía duy nhất nói chuyện trực tiếp với DB
- API là gì? Tại sao mọi app đều cần — cách frontend lấy data từ DB qua backend (sắp có)
- Web hoạt động thế nào — hành trình 200ms — DB là bước 4 trong chuỗi 5 bước
- Domain, Hosting, DNS — 3 thứ bạn mua — hosting bao gồm cả nơi đặt DB (sắp có)