Sự khác biệt giữa embedding và referencing là gì?

Question

Accepted Answer

**Embedding** lưu dữ liệu liên quan *bên trong* một document (lồng nhau); **referencing** lưu nó trong các document *riêng biệt* liên kết bằng id. Đây là quyết định mô hình hóa cốt lõi trong MongoDB, với những đánh đổi khác nhau về hiệu năng đọc, kích thước dữ liệu, và độ phức tạp cập nhật.

## Embedding — lồng nhau trong document

```js
{
  _id: ObjectId("..."),
  title: "My Post",
  author: { name: "Ann", email: "ann@x.com" },   // author NHÚNG
  comments: [                                      // comments NHÚNG
    { user: "Bob", text: "Great!" },
    { user: "Carol", text: "Thanks" }
  ]
}
// ✓ MỘT truy vấn lấy post + author + comments (nhanh, atomic)
// ✗ nếu thông tin author thay đổi, phải cập nhật trong mọi post nhúng nó (trùng lặp)
// ✗ document tăng theo comments → có thể chạm giới hạn 16MB nếu vô hạn
```

## Referencing — document riêng biệt liên kết bằng id

```js
// collection posts
{ _id: ObjectId("p1"), title: "My Post", authorId: ObjectId("u1") }
// collection users
{ _id: ObjectId("u1"), name: "Ann", email: "ann@x.com" }
// collection comments
{ _id: ObjectId("c1"), postId: ObjectId("p1"), user: "Bob", text: "Great!" }

// ✓ author/comments lưu MỘT LẦN, cập nhật một chỗ; không vấn đề kích thước document
// ✓ mỗi thực thể được quản lý độc lập
// ✗ cần nhiều truy vấn hoặc $lookup để kết hợp (đọc dữ liệu liên quan chậm hơn)
```

## Các đánh đổi cạnh nhau

```text
                  Embedding                    Referencing
Đọc               ✓ nhanh (một truy vấn)        ✗ nhiều truy vấn / $lookup
Trùng lặp dữ liệu ✗ trùng (cập nhật nhiều)      ✓ lưu một lần
Kích thước doc    ✗ tăng (rủi ro giới hạn 16MB) ✓ không lo kích thước
Cập nhật          ✗ cập nhật mọi bản sao        ✓ cập nhật một chỗ
Atomicity         ✓ atomic (một document)       ✗ qua nhiều document
Tốt cho           chứa đựng, truy cập-cùng-nhau chia sẻ, lớn, độc lập, nhiều
```

## Cách tiếp cận lai (phổ biến)

```js
// nhúng một TẬP CON cho đọc nhanh, reference cho dữ liệu đầy đủ
{ title: "Post", author: { _id: ObjectId("u1"), name: "Ann" } }  // đủ để hiển thị
// → reference (author._id) cho chi tiết đầy đủ khi cần; nhúng name cho lần đọc phổ biến
```

## Tại sao điều này quan trọng

Hiểu embedding vs referencing là **kỹ năng cốt lõi của mô hình hóa dữ liệu MongoDB**, nên đây là kiến thức thiết yếu để thiết kế ứng dụng MongoDB hiệu quả.

Quyết định này — lưu dữ liệu liên quan bên trong một document (embedding) vs trong các document liên kết riêng biệt (referencing) — trực tiếp quyết định hiệu năng đọc, tính nhất quán dữ liệu, kích thước document, và độ phức tạp cập nhật của ứng dụng, khiến nó là lựa chọn thiết kế hệ trọng nhất của MongoDB.

Hiểu các **đánh đổi** là then chốt: **embedding** cho đọc một-truy-vấn nhanh dữ liệu liên quan và cập nhật atomic (phù hợp với quan hệ "chứa đựng", dữ liệu truy cập cùng nhau, sub-data có giới hạn) nhưng gây trùng lặp (phức tạp cập nhật nếu dữ liệu được chia sẻ) và document tăng kích thước (rủi ro giới hạn 16MB nếu vô hạn); **referencing** lưu dữ liệu một lần (cập nhật dễ, không trùng lặp, không vấn đề kích thước, quản lý độc lập) nhưng yêu cầu nhiều truy vấn hoặc `$lookup` để kết hợp (đọc dữ liệu liên quan chậm hơn).

Biết loại nào phù hợp với kịch bản nào — embed cho dữ liệu có giới hạn, được sở hữu, truy cập cùng nhau; reference cho dữ liệu lớn, chia sẻ, độc lập, hoặc quan hệ nhiều — là sự phán đoán mô hình hóa thiết yếu.

Hiểu **cách tiếp cận lai** phổ biến (nhúng một tập con cho đọc nhanh trong khi reference cho dữ liệu đầy đủ — đạt được cái tốt nhất của cả hai) phản ánh thiết kế tinh tế.

Vì quyết định này ảnh hưởng sâu sắc đến chất lượng ứng dụng MongoDB (lựa chọn sai gây truy vấn chậm, document phình to, hoặc cập nhật đau đớn), và vì nó là kỹ năng mô hình hóa MongoDB cơ bản, đặc trưng (không có tương đương SQL trực tiếp — SQL chuẩn hóa mặc định), nên hiểu embedding vs referencing — các đánh đổi, khi nào dùng mỗi loại, và cách tiếp cận lai — là kiến thức thiết yếu, giá trị cao nằm ở trung tâm của mô hình hóa dữ liệu MongoDB hiệu quả và một trong những chủ đề MongoDB quan trọng và được bàn luận nhiều nhất, trung tâm của việc thiết kế schema hoạt động tốt cho access pattern của ứng dụng.