Đã đăng vào Thứ Bảy, 5:00 SA 9 phút đọc

📍Lựa chọn cơ sở dữ liệu phù hợp

"Nên dùng SQL hay NoSQL? B-Tree hay LSM Tree?"Nếu bạn từng cảm thấy bối rối khi chọn cơ sở dữ liệu phù hợp cho ứng dụng của mình, thì bạn không đơn độc. Đằng sau mỗi hệ quản trị cơ sở dữ liệu là cả một thế giới phức tạp gồm các bộ máy lưu trữ và cơ chế xử lý giao dịch - và quyết định đúng có thể tạo nên sự khác biệt giữa hiệu năng siêu tốc và những điểm nghẽn đau đầu.

📖 Một trải nghiệm nhỏ.

Mọi chuyện bắt đầu khi tôi thiết kế backend cho một ứng dụng thương mại điện tử đang phát triển với tốc độ chóng mặt. Hệ thống cần phục vụ hàng ngàn người dùng đồng thời, cập nhật tồn kho sản phẩm theo thời gian thực, gợi ý sản phẩm được cá nhân hóa, và có một bảng điều khiển (dashboard) phải cập nhật nhanh hơn cả khi bạn kịp thốt lên “hết hàng rồi!”

Và giống như bao nhà phát triển khác, tôi cũng rơi vào câu hỏi kinh điển:

“Nên chọn cơ sở dữ liệu nào đây?”

Từ đó, tôi bắt đầu chuyến hành trình khám phá sâu vào thế giới bên trong của cơ sở dữ liệu — nơi các bộ máy lưu trữ so tài, các giao dịch hoạt động như một bản khiêu vũ nhịp nhàng, và nơi mà mỗi quyết định đều mang theo nhiều mặt được/mất.

🔍 Bên trong một hệ cơ sở dữ liệu

Thoạt nhìn, cơ sở dữ liệu trông thật đơn giản: thêm dữ liệu, truy vấn, cập nhật, xóa.

Nhưng không !!! Thực tế, nó giống như một cỗ máy nhiều tầng lớp:

Transport: nơi truy vấn của bạn được gửi đến máy chủ
Parser & Optimizer: nơi SQL được phân tích và tối ưu
Execution Engine: nơi công việc thực sự diễn ra
Storage Engine: trái tim của toàn hệ thống

Và từ đây, hành trình thực sự bắt đầu...

🍊 So găng Storage Engine: B-Tree vs LSM Tree

🎓 B-Tree – Người anh hùng cổ điển

Hãy tưởng tượng một thư viện cổ, nơi mọi thứ đều được sắp xếp trật tự, có nhãn rõ ràng. Đó chính là cách B-Tree hoạt động:

Dữ liệu được lưu thành các khối đã sắp xếp
Truy vấn cực nhanh (O(log n))
Cập nhật trực tiếp tại chỗ (một số I/O đĩa ngẫu nhiên, nhưng điều đó không sao đối với các hệ thống OLTP)

Các cơ sở dữ liệu như MySQL (InnoDB) và PostgreSQL thích B-Trees. Chúng cực kỳ chắc chắn khi bạn cần tính nhất quán cao, tra cứu nhanh và ACID transactions.

🔥 LSM Tree – Kẻ thay đổi cuộc chơi

LSM Tree — Log-Structured Merge Tree — hoạt động khác hẳn.

Không cập nhật tại chỗ, mà ghi vào bộ nhớ tạm (MemTable), rồi định kỳ ghi ra đĩa thành các tập tin được sắp xếp (SSTable). Sau đó là quá trình "compaction" để hợp nhất dữ liệu.

Giống như bạn viết ghi chú ra giấy nhớ, rồi tổng hợp lại thành sổ tay gọn gàng sau.

Kết quả? Ghi dữ liệu cực nhanh. Lý tưởng cho log, telemetry, IoT, hoặc các hệ thống ghi-heavy.

Cassandra, RocksDB, HBase, và MongoDB (WiredTiger) sử dụng LSM Tree.

⚖️ Khi bạn phải lựa chọn

B-Tree phù hợp nếu	LSM Tree phù hợp nếu..
Đọc nhiều hơn ghi	Ghi nhiều hơn đọc
Cần tuân thủ ACID chặt chẽ	Chấp nhận nhất quán cuối cùng (BASE)
OLTP-style transactions	Streaming or time-series data

Một cơ sở dữ liệu tốt không chỉ đơn thuần là chuyện đọc hay ghi dữ liệu...

🔐 Transaction — Bức tranh tinh vi

Giống như một vụ trộm công nghệ cao: Thời điểm là tất cả.

Transaction yêu cầu tính ACID : Atomic, Consistent, Isolated, and Durable

✪️ Với SQL (Relational DB)

Trong các hệ thống như MySQL hoặc PostgreSQL, việc đảm bảo các nguyên tắc ACID được thực hiện thông qua các cơ chế như:

Undo Logs – ghi lại thao tác để có thể hoàn tác nếu có lỗi
Write-Ahead Logs (WAL) – luôn ghi log trước khi thực hiện thay đổi dữ liệu
MVCC (Multi-Version Concurrency Control) – kiểm soát đồng thời bằng cách duy trì nhiều phiên bản dữ liệu Mọi thay đổi đều được theo dõi và có thể đảo ngược.

🌐 Với NoSQL

Ngược lại, những hệ thống như Cassandra và DynamoDB lại ưu tiên tính nhất quán cuối cùng (eventual consistency) — chúng tuân theo mô hình BASE, viết tắt của:

Basically Available – luôn sẵn sàng phục vụ
Soft state – trạng thái có thể thay đổi theo thời gian
Eventual consistency – cuối cùng sẽ nhất quán

Hình dung đơn giản: chúng hoạt động giống như những cuốn sổ tay ghi chú mà các thành viên trong nhóm cập nhật dần theo thời gian.

Dữ liệu được cập nhật trước ở một nút, và các nút còn lại sẽ “đuổi theo” để đồng bộ sau. Mọi thứ diễn ra nhanh, phân tán, nhưng đổi lại là sự lỏng lẻo về tính nhất quán so với các hệ SQL truyền thống.

🧵 Xử lý đồng thời

Tính đồng thời là nơi mọi thứ bắt đầu trở nên... rắc rối hơn.

🔐 Với B-Tree:

Tính đồng thời được kiểm soát bằng cơ chế khóa tinh vi:

Shared locks (khóa chia sẻ)
Exclusive locks (khóa độc quyền)
Update locks (khóa cập nhật)

Thậm chí còn có một biến thể thông minh gọi là B-Link Tree, cho phép các truy vấn đọc vẫn có thể diễn ra ngay cả khi dữ liệu đang được ghi.

⚡ Còn với LSM Tree:

Tất cả lại theo một hướng gần như không dùng khóa:

MemTable có thể nhận nhiều lượt ghi cùng lúc
SSTable là bất biến – đọc không cần khóa
Quá trình compaction diễn ra âm thầm ở hậu trường

So sánh đơn giản:

B-Tree giống như một kho tiền với lớp bảo vệ nhiều tầng – cẩn thận và chắc chắn.
LSM Tree lại giống như một cửa quay tự động – nhẹ nhàng, linh hoạt, và không cần đứng chờ.

🧬 Kỷ nguyên lai (Hybrid Age)

Trong thế giới thực, không có cơ sở dữ liệu nào “vừa vặn cho tất cả”.

Vì vậy, ngày càng nhiều hệ thống bắt đầu** kết hợp những điểm mạnh của cả hai thế giới** – vừa tận dụng tính nhất quán, vừa đảm bảo hiệu năng cao:

MySQL hỗ trợ plugin RocksDB để tận dụng LSM Tree khi cần hiệu suất ghi tốt hơn
MongoDB đã chuyển sang sử dụng WiredTiger – một engine hoạt động gần giống với LSM
Amazon Aurora kết hợp khả năng viết truy vấn SQL với hiệu năng gần như của NoSQL

Sự lai tạo này giúp các hệ thống vừa linh hoạt, vừa mạnh mẽ – mở ra hướng đi mới cho các ứng dụng có nhu cầu phức tạp.

🧠 Bài học rút ra

Chọn cơ sở dữ liệu phù hợp không phải là chuyện chạy theo xu hướng — mà là việc đánh đổi giữa các yếu tố.

Hãy tự hỏi bản thân:

Tải công việc của bạn có chủ yếu là đọc hay ghi dữ liệu?
Bạn có cần strict transactions không, hay tốc độ quan trọng hơn?
Bạn đang xử lý theo structured business data, hay hàng triệu streaming events?

Khi bạn trả lời được những câu hỏi này, storage engine phù hợp sẽ gần như tự chọn mình.

✍️ Lời kết

Dòng lệnh insert into users trong code bạn viết có thể trông đơn giản — nhưng phía sau là cả một hệ sinh thái công nghệ đã phát triển hàng thập kỷ.

Hiểu rõ cách hoạt động bên trong của hệ quản trị cơ sở dữ liệu sẽ giúp bạn phát triển thành một backend engineer giỏi hơn. Hy vọng, bài viết này sẽ là bước đầu cho hành trình đó.