Login

MongoDB cho người mới: document, collection và thiết kế schema

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

MongoDB lưu dữ liệu dưới dạng tài liệu giống JSON thay vì các hàng và cột cố định. Cách tiếp cận này linh hoạt và gần với cách lập trình viên nghĩ về đối tượng, nhưng cũng dễ bị dùng sai nếu bạn đem tư duy quan hệ áp dụng nguyên xi. Bài này giúp bạn bắt đầu đúng.

Các khái niệm cơ bản

  • Document: một bản ghi dạng JSON (lưu nội bộ dạng BSON), có thể lồng nhau và chứa mảng.
  • Collection: nhóm các document, tương đương bảng nhưng không ép cấu trúc cố định.
  • Database: chứa nhiều collection.

Mỗi document có trường _id duy nhất, mặc định là ObjectId do hệ thống tạo.

Thao tác cơ bản

// mongoshuse shopdb.products.insertOne({  name: "Bàn phím cơ",  price: 850000,  tags: ["phụ kiện", "gaming"],  specs: { switch: "red", layout: "tkl" }})db.products.find({ price: { $lt: 1000000 }, tags: "gaming" })db.products.find({}, { name: 1, price: 1, _id: 0 }).sort({ price: -1 }).limit(5)db.products.updateOne({ name: "Bàn phím cơ" }, { $set: { price: 800000 } })db.products.deleteOne({ name: "Bàn phím cơ" })

Toán tử bắt đầu bằng $ như $lt, $in, $set, $push là cách diễn đạt điều kiện và cập nhật. Truy vấn vào trường lồng nhau dùng dấu chấm: "specs.switch": "red".

Nhúng hay tham chiếu?

Đây là quyết định thiết kế quan trọng nhất. Nhúng (embedding) đặt dữ liệu liên quan vào trong cùng document:

{  _id: 1,  title: "Bài viết đầu",  comments: [    { user: "An", text: "Hay quá" },    { user: "Bình", text: "Cảm ơn bạn" }  ]}

Tham chiếu (referencing) lưu id trỏ sang collection khác, giống khóa ngoại:

{ _id: 1, title: "Bài viết đầu", authorId: ObjectId("...") }

Nên nhúng khi dữ liệu luôn được đọc cùng nhau, quan hệ một-nhiều với số lượng nhỏ và có giới hạn, và dữ liệu con không cần truy cập độc lập. Nên tham chiếu khi dữ liệu con có thể lớn không giới hạn (hàng triệu bình luận), được dùng ở nhiều nơi, hoặc thay đổi thường xuyên. Document có kích thước tối đa 16 MB, nên đừng nhúng mảng phình vô hạn.

Thiết kế theo cách truy cập

Khác với thiết kế quan hệ bắt đầu từ chuẩn hóa dữ liệu, trong MongoDB bạn nên bắt đầu từ câu hỏi: ứng dụng sẽ đọc và ghi dữ liệu như thế nào? Cấu trúc document nên phục vụ các truy vấn phổ biến nhất, thậm chí chấp nhận lặp lại một ít dữ liệu (denormalize) để đọc nhanh với một lần truy vấn. Đổi lại, khi dữ liệu lặp thay đổi, bạn phải cập nhật ở nhiều nơi, nên chỉ lặp những thứ ít đổi.

Chỉ mục

db.products.createIndex({ price: 1 })db.products.createIndex({ tags: 1, price: -1 })db.users.createIndex({ email: 1 }, { unique: true })db.products.find({ tags: "gaming" }).explain("executionStats")

Cũng như database quan hệ, thiếu chỉ mục khiến truy vấn quét toàn bộ collection. Dùng explain để kiểm tra, và nhớ rằng thứ tự trường trong chỉ mục kết hợp quan trọng.

Aggregation pipeline

db.orders.aggregate([  { $match: { status: "paid" } },  { $group: { _id: "$userId", total: { $sum: "$amount" } } },  { $sort: { total: -1 } },  { $limit: 10 }])

Pipeline gồm các bước nối tiếp, mỗi bước biến đổi dữ liệu: lọc, gom nhóm, sắp xếp, nối bảng ($lookup). Đây là công cụ mạnh cho báo cáo và thống kê.

Khi nào chọn MongoDB?

MongoDB hợp với dữ liệu có cấu trúc linh hoạt hoặc thay đổi thường xuyên, như danh mục sản phẩm với thuộc tính khác nhau, nhật ký sự kiện, nội dung. Nếu dữ liệu có nhiều quan hệ phức tạp, cần transaction nhiều bảng và báo cáo kiểu SQL, database quan hệ thường đơn giản hơn. Hiện MongoDB cũng hỗ trợ transaction nhiều document, nhưng thiết kế tốt vẫn là giảm nhu cầu dùng chúng.

Sai lầm thường gặp với MongoDB

Sai lầm đầu tiên là coi MongoDB như nơi "muốn lưu gì cũng được". Thiếu kỷ luật về cấu trúc, dữ liệu dần lộn xộn với cùng một trường khi thì là số khi thì là chuỗi. Hãy dùng kiểm tra schema (JSON Schema validation) của MongoDB hoặc thư viện ODM như Mongoose để áp đặt quy tắc ở tầng ứng dụng. Sai lầm thứ hai là nhúng mảng không giới hạn, khiến document ngày càng lớn và chậm. Sai lầm thứ ba là thiếu chỉ mục cho các truy vấn thường dùng. Sai lầm cuối là bỏ qua sao lưu; hãy thiết lập sao lưu định kỳ và thử khôi phục thật sự, vì một bản sao lưu chưa từng được thử khôi phục thì chưa đáng tin.

Kết luận

Sức mạnh của MongoDB đến từ thiết kế document phù hợp cách truy cập, không phải từ việc "không cần schema". Hãy cài thử MongoDB, mô hình hóa một blog với bài viết và bình luận theo cả hai cách nhúng và tham chiếu, rồi so sánh truy vấn của hai thiết kế.

Khi cần một lộ trình học có hệ thống, bạn có thể tham khảo khóa học trên codebem.com.

author_photo
Nguyễn Đình Cường

0 comment