Khởi Đầu Nhanh: SQL vs NoSQL Trong 5 Phút
Khi bắt đầu một dự án mới, ai đó hỏi “MySQL hay MongoDB?” — câu hỏi này làm nhiều kỹ sư bối rối ngay từ đầu. Đây là phiên bản ngắn gọn trước khi đi vào chi tiết.
Cơ sở dữ liệu SQL (PostgreSQL, MySQL, SQLite) lưu dữ liệu trong các bảng với schema cố định. Hãy hình dung như một bảng tính: các cột được định nghĩa trước, mỗi hàng có cùng cấu trúc, và các quan hệ giữa các bảng được định nghĩa và ràng buộc rõ ràng.
Cơ sở dữ liệu NoSQL (MongoDB, Redis, Cassandra, DynamoDB) bỏ qua cấu trúc cứng nhắc đó. Document, cặp key-value, đồ thị, wide column — mỗi loại NoSQL giải quyết một vấn đề cụ thể khác nhau.
Đây là bảng tóm tắt 30 giây:
- SQL: Dữ liệu có cấu trúc, truy vấn phức tạp, giao dịch ACID → thương mại điện tử, ngân hàng, CRM
- NoSQL: Schema linh hoạt, quy mô lớn, access pattern cụ thể → social feed, cache, phân tích thời gian thực
Thực tế luôn phức tạp hơn bất kỳ bảng tóm tắt nào. Hãy cùng xem khi nào mỗi loại thực sự chiếm ưu thế.
Phân Tích Sâu: Sự Khác Biệt Thực Sự
Schema: Cứng Nhắc vs Linh Hoạt
SQL yêu cầu bạn định nghĩa schema trước khi ghi bất kỳ dòng nào. Muốn thêm cột sau? Bạn phải chạy migration ALTER TABLE, điều này có thể rất đau đầu với các bảng lớn trên production.
-- Schema được định nghĩa trước
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(255) UNIQUE NOT NULL,
created_at TIMESTAMP DEFAULT NOW()
);
-- Thêm trường sau này cần migration
ALTER TABLE users ADD COLUMN phone VARCHAR(20);
MongoDB cho phép bạn thêm bất kỳ trường nào tùy ý, cho từng document:
// Mỗi document có thể có các trường khác nhau
db.users.insertMany([
{ email: "[email protected]", phone: "+1234567890" },
{ email: "[email protected]", preferences: { theme: "dark" } }
]);
Ở giai đoạn đầu dự án, sự linh hoạt đó là ưu điểm thực sự — yêu cầu thay đổi hàng ngày và bạn không muốn viết migration mỗi buổi chiều. Vấn đề sẽ xuất hiện về sau. Hãy thử truy vấn 50 triệu document với các trường hơi khác nhau và bạn sẽ nhanh chóng hiểu tại sao kỷ luật về schema lại quan trọng.
Quan Hệ: JOINs vs Nhúng (Embedding)
SQL được xây dựng cho điều này. Các quan hệ phức tạp giữa các thực thể — đơn hàng, khách hàng, sản phẩm, hóa đơn — được mô hình hóa gọn gàng bằng foreign key và JOIN.
-- Truy vấn qua các bảng có quan hệ
SELECT
u.email,
COUNT(o.id) AS order_count,
SUM(o.total) AS total_spent
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.created_at >= '2024-01-01'
GROUP BY u.email
ORDER BY total_spent DESC;
MongoDB xử lý điều này theo cách khác. Bạn có thể nhúng dữ liệu liên quan vào trong document (đọc nhanh, trùng lặp dữ liệu) hoặc dùng tham chiếu tương tự foreign key — nhưng phải quản lý thủ công. Không cách nào gọn gàng như SQL cho các truy vấn quan hệ phức tạp.
Mở Rộng: Theo Chiều Dọc vs Theo Chiều Ngang
Cơ sở dữ liệu SQL truyền thống mở rộng theo chiều dọc — bạn thêm CPU và RAM vào cùng một máy chủ. Cách này hoạt động tốt cho đến khi không còn hiệu quả, và chi phí tăng nhanh chóng.
Cơ sở dữ liệu NoSQL được thiết kế từ đầu để mở rộng theo chiều ngang: thêm máy chủ, phân mảnh dữ liệu qua chúng. Đó là cách Cassandra xử lý hàng trăm terabyte, hay cách DynamoDB phục vụ hàng triệu request mỗi giây trên hạ tầng AWS.
PostgreSQL hiện đại với read replica và các công cụ như Citus xử lý việc mở rộng theo chiều ngang tốt hơn nhiều so với danh tiếng của nó. Đừng nghĩ SQL không thể mở rộng — nó chỉ mở rộng theo cách khác.
ACID vs Eventual Consistency
Cơ sở dữ liệu SQL cung cấp đảm bảo ACID:
- Atomicity: Giao dịch thất bại sẽ rollback hoàn toàn — tất cả hoặc không có gì
- Consistency: Dữ liệu luôn tuân theo các quy tắc bạn đã định nghĩa
- Isolation: Các giao dịch đồng thời không can thiệp vào nhau
- Durability: Dữ liệu đã commit sẽ tồn tại qua các sự cố
Hầu hết cơ sở dữ liệu NoSQL đánh đổi một số đảm bảo này để lấy hiệu năng và tính khả dụng. Thuật ngữ kỹ thuật là eventual consistency — dữ liệu của bạn sẽ nhất quán, chỉ là không ngay lập tức. Với giỏ hàng, điều đó ổn. Với chuyển khoản ngân hàng — tuyệt đối không.
Ứng Dụng Nâng Cao: Các Tình Huống Thực Tế
Khi SQL Chiếm Ưu Thế
Ứng dụng tài chính: Chuyển khoản ngân hàng cần giao dịch atomic. Bạn không thể để tiền biến mất giữa hai tài khoản vì máy chủ bị crash giữa chừng. PostgreSQL với transaction isolation phù hợp là lựa chọn đúng đắn.
BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
COMMIT;
-- Nếu có bất kỳ lỗi nào, toàn bộ giao dịch sẽ rollback
Báo cáo và phân tích: Tổng hợp phức tạp qua nhiều bảng, window function, CTE — SQL có lợi thế 40 năm ở đây. Các công cụ BI như Metabase và Grafana hỗ trợ SQL tự nhiên, giúp bạn tiết kiệm đáng kể công sức tích hợp.
Sản phẩm trưởng thành với schema ổn định: Khi mô hình dữ liệu đã ổn định, sự cứng nhắc của SQL trở thành ưu điểm. Schema của bạn ghi lại mô hình domain và ngăn chặn dữ liệu xấu ngay ở tầng cơ sở dữ liệu.
Khi NoSQL Chiếm Ưu Thế
Quản lý nội dung và danh mục: Danh mục sản phẩm mà mỗi mặt hàng có thuộc tính khác nhau hoàn toàn rất phù hợp với mô hình document của MongoDB. TV có độ phân giải và loại màn hình; sách có ISBN và số trang. Mô hình hóa điều này trong SQL đồng nghĩa với cột nullable ở khắp nơi hoặc các pattern EAV phức tạp.
// Sản phẩm với cấu trúc hoàn toàn khác nhau — hoạt động tốt trong MongoDB
db.products.insertMany([
{
type: "tv",
brand: "Sony",
resolution: "4K",
panel: "OLED",
size_inches: 55
},
{
type: "book",
title: "Clean Code",
author: "Robert Martin",
isbn: "978-0132350884",
pages: 431
}
]);
Cache và session: Redis là tiêu chuẩn ở đây. Đọc dưới mili giây, TTL expiry, các cấu trúc dữ liệu như list và sorted set. Chạy Redis như tầng cache trước PostgreSQL là một trong những cấu hình production phổ biến nhất tôi từng làm việc.
# Cache session người dùng với thời hạn 24h
redis-cli SET "session:abc123" '{"user_id": 42, "role": "admin"}' EX 86400
# Lấy lại dữ liệu
redis-cli GET "session:abc123"
Khối lượng ghi cao thời gian thực: Dữ liệu cảm biến IoT, event log, luồng hoạt động người dùng — Cassandra và DynamoDB xử lý hàng triệu lần ghi mỗi giây mà không cần gắng sức. Đẩy khối lượng đó qua MySQL sẽ cần thêm rất nhiều công sức kỹ thuật.
Polyglot Persistence: Dùng Cả Hai
Câu trả lời tốt nhất trên production thường là: dùng cả hai. Được gọi là polyglot persistence, cách tiếp cận này giao mỗi loại dữ liệu cho cơ sở dữ liệu phù hợp nhất — thay vì ép một công cụ làm tất cả mọi thứ.
Một stack thương mại điện tử điển hình có thể trông như sau:
- PostgreSQL: Đơn hàng, thanh toán, tồn kho — quan hệ, quan trọng với ACID
- MongoDB: Danh mục sản phẩm — schema linh hoạt theo danh mục
- Redis: Session, giỏ hàng, rate limiting — quan trọng về tốc độ
- Elasticsearch: Tìm kiếm sản phẩm — full-text, faceting
Nhiều thành phần hơn để quản lý, đúng vậy — nhưng không có gì bị ép vào vai trò mà nó không được thiết kế để đảm nhận.
Mẹo Thực Tế
Bắt Đầu với PostgreSQL, Migrate Khi Cần
Khuyến nghị mặc định của tôi cho bất kỳ dự án mới nào: bắt đầu với PostgreSQL. Nó đáng tin cậy, có tooling xuất sắc, hỗ trợ cột JSON tự nhiên (điều này thu hẹp đáng kể khoảng cách SQL/NoSQL), và có thể xử lý tải nhiều hơn hầu hết dự án sẽ bao giờ đạt được. Thêm Redis để cache sau nếu cần, hoặc migrate các hot path cụ thể sang NoSQL khi bạn gặp bottleneck thực sự.
Kiến trúc database quá sớm là một cái bẫy thực sự. Tôi đã thấy các team dành hàng tuần thiết kế cluster Cassandra cho một ứng dụng không bao giờ có hơn 100 người dùng.
Lập Bản Đồ Access Pattern Trước Khi Chọn
Trước khi chọn cơ sở dữ liệu, hãy viết ra 5 pattern truy vấn hàng đầu của bạn. Nếu tất cả đều là “lấy document theo ID” hay “lấy tất cả item của người dùng X,” thì database document là hợp lý. Nếu là tổng hợp, báo cáo hay JOIN nhiều bảng, hãy ở lại SQL. Access pattern quyết định nhiều hơn bất kỳ yếu tố nào khác.
Chú Ý Định Dạng Dữ Liệu Khi Migration
Chuyển đổi định dạng xuất hiện liên tục khi di chuyển giữa các hệ thống cơ sở dữ liệu — ví dụ như export CSV từ PostgreSQL để đưa vào MongoDB. Khi cần chuyển đổi nhanh CSV sang JSON để import dữ liệu, tôi dùng toolcraft.app/vi/tools/data/csv-to-json. Nó chạy hoàn toàn trên trình duyệt, nên không có dữ liệu nào rời khỏi máy bạn — điều này rất quan trọng khi bạn xử lý dữ liệu khách hàng.
Đừng Coi NoSQL là Hoàn Toàn Không Có Schema
Chỉ vì MongoDB không ép buộc schema không có nghĩa là bạn không nên có schema. Thêm validation ở tầng ứng dụng, hoặc dùng tính năng JSON Schema validation tích hợp của MongoDB. Schema phát triển không kiểm soát là cách bạn kết thúc với một collection không thể truy vấn đáng tin cậy sau sáu tháng.
// Ép buộc schema validation ở cấp collection
db.createCollection("users", {
validator: {
$jsonSchema: {
bsonType: "object",
required: ["email", "created_at"],
properties: {
email: { bsonType: "string" },
created_at: { bsonType: "date" }
}
}
}
});
Ưu Tiên Managed Service Khi Có Thể
Trước khi tự host bất kỳ cơ sở dữ liệu nào, hãy kiểm tra những gì cloud provider của bạn cung cấp. RDS cho PostgreSQL/MySQL, DynamoDB, DocumentDB, ElastiCache — các dịch vụ này xử lý backup, failover và patching cho bạn. Tự host cluster Cassandra thực chất là một công việc toàn thời gian. Tự host PostgreSQL trên VPS cho dự án nhỏ? Hoàn toàn hợp lý. Hãy biết chi phí vận hành trước khi cam kết.
Không có câu trả lời đúng tuyệt đối ở đây. Hãy chọn dựa trên access pattern và nhu cầu nhất quán của bạn. Bắt đầu với thứ đã được chứng minh — PostgreSQL xử lý tốt cho đa số ứng dụng. Chỉ thêm độ phức tạp khi một bottleneck thực sự, đo lường được buộc bạn phải làm vậy. Sơ đồ kiến trúc hoành tráng nhất trong phòng thường là cái sai nhất để xây dựng.
