Nền tảng MongoDB

Mục lục

• Mục tiêu học tập
• Cách đọc phần Nền tảng
  • Chọn lối vào phù hợp
  • Học theo vòng lặp nhỏ
• Bản đồ khái niệm
• Các khái niệm nền tảng
  • MongoDB là gì?
  • Document, collection và database
  • BSON và kiểu dữ liệu
  • Kiến trúc MongoDB
  • MongoDB và cơ sở dữ liệu SQL
• Lộ trình đọc đề xuất
• Bẫy thường gặp và nguyên tắc thực hành
• Toàn bộ bài trong phần
• Bước tiếp theo trong lộ trình

Mục tiêu học tập

Sau khi hoàn thành phần này, bạn nên có thể:

Cách đọc phần Nền tảng

Chọn lối vào phù hợp

Không phải người học nào cũng bắt đầu từ cùng một điểm. Chọn lối đọc gần với kinh nghiệm hiện tại, nhưng hãy quay lại đọc đủ năm bài trước khi thiết kế schema (quy tắc cấu trúc và field của dữ liệu) cho một hệ thống thật.

Học theo vòng lặp nhỏ

Mỗi bài nên tạo ra một kết quả có thể kiểm tra. Cách này hiệu quả hơn việc đọc hết lý thuyết rồi mới thử lệnh.

Bản đồ khái niệm

Sơ đồ dưới đây tách hai lớp thường bị trộn lẫn: mô hình logic của dữ liệu và topology (cách các tiến trình MongoDB được bố trí để phục vụ workload). Workload là tải đọc/ghi mà ứng dụng tạo ra; access pattern — mẫu truy vấn và cập nhật mà ứng dụng thực sự chạy — nối hai lớp đó lại vì nó ảnh hưởng cả schema lẫn index.

Cách đọc sơ đồ:

• Ứng dụng → driver → topology là đường đi của request. Driver là thư viện ngôn ngữ giúp ứng dụng mở kết nối, mã hóa lệnh và đọc kết quả từ MongoDB.
• Database → collection → document là cấu trúc logic. Nó mô tả dữ liệu được nhóm ra sao, không nói rằng mỗi collection phải giống một bảng SQL.
• Document BSON là đơn vị dữ liệu mà MongoDB đọc và ghi một cách nguyên tử ở cấp document. BSON là cách biểu diễn nhị phân có thêm các kiểu như Date, ObjectId và Decimal128.
• Access pattern → mô hình document là hướng suy nghĩ quan trọng nhất. Ta thiết kế document từ cách ứng dụng đọc và ghi, thay vì chuyển nguyên xi sơ đồ bảng sang collection.
• Topology quyết định tính sẵn sàng và khả năng mở rộng. Một mongod đơn lẻ đơn giản hơn; replica set thêm bản sao và failover; sharded cluster phân phối dữ liệu nhưng đòi hỏi vận hành và shard key cẩn thận.

Các khái niệm nền tảng

Năm bài trong phần này liên kết với nhau. Các mục dưới đây là bản xem trước để bạn biết mỗi bài trả lời câu hỏi nào và vì sao nó xuất hiện trong lộ trình.

MongoDB là gì?

MongoDB là gì? trả lời câu hỏi nền tảng: MongoDB phù hợp với loại workload nào và document database khác gì so với mô hình quan hệ. Document database lưu một thực thể cùng các thuộc tính liên quan trong một document có cấu trúc giống object (đối tượng gồm các cặp key–value). Cách này thường thuận tiện khi ứng dụng đọc một thực thể cùng dữ liệu con của nó.

Ví dụ, một đơn hàng có thể giữ các mặt hàng và địa chỉ giao hàng trong cùng document:

use shop

db.orders.insertOne({
  customerId: ObjectId("65a000000000000000000010"),
  status: "paid",
  items: [
    {
      sku: "MUG-001",
      name: "MongoDB mug",
      quantity: 2,
      unitPrice: Decimal128("12.50")
    }
  ],
  shippingAddress: {
    city: "Da Nang",
    country: "VN"
  },
  createdAt: ISODate("2025-01-15T10:30:00Z")
})

Trong ví dụ này, orders là collection và object truyền vào insertOne() là document. items là mảng các document lồng nhau. shippingAddress là một document lồng nhau khác. Vì không tự cung cấp _id, MongoDB sẽ tạo một _id duy nhất cho document đơn hàng.

Lệnh sau đọc các đơn đã thanh toán tại Việt Nam và chỉ trả về những field cần dùng:

db.orders.find(
  { status: "paid", "shippingAddress.country": "VN" },
  { _id: 0, status: 1, items: 1 }
)

Dấu chấm trong shippingAddress.country là dot notation, cú pháp truy cập field lồng nhau. Đối số thứ hai là projection, tức danh sách field cần trả về. Ví dụ cho thấy document model không chỉ là cách lưu dữ liệu; nó ảnh hưởng trực tiếp đến cách ứng dụng đọc dữ liệu.

Document, collection và database

Document, collection và database giải thích ba cấp tổ chức dữ liệu. Có thể hình dung chúng như sau:

database: shop
└── collection: orders
    ├── document: một đơn hàng
    │   ├── field: status
    │   ├── field: createdAt
    │   ├── array: items[]
    │   └── embedded document: shippingAddress
    └── document: một đơn hàng khác

• Database là không gian logic chứa các collection.
• Collection là nhóm các document có liên quan. MongoDB cho phép các document trong cùng collection có field khác nhau nếu bạn không đặt validation.
• Document là bản ghi dạng key-value, có thể chứa scalar value (giá trị đơn như chuỗi hoặc số), mảng và document lồng nhau.
• Field là một cặp tên–giá trị trong document. _id là field định danh; mỗi document trong một collection phải có _id duy nhất.

Schema linh hoạt không có nghĩa là mọi document đều nên tùy ý. Ứng dụng vẫn cần quy ước field bắt buộc, kiểu dữ liệu và trạng thái hợp lệ. Khi collection có nhiều writer hoặc dữ liệu quan trọng, có thể bổ sung schema validation (cơ chế kiểm tra cấu trúc document) ở database để bắt lỗi sớm.

Trade-off chính là locality (đặt dữ liệu được đọc cùng nhau ở gần nhau) so với khả năng cập nhật độc lập. Nhúng items giúp đọc một đơn hàng nhanh và tự nhiên. Nếu một mảng tăng không giới hạn hoặc phần tử được nhiều đơn hàng dùng chung, tham chiếu sang collection khác có thể an toàn hơn. Hãy để access pattern quyết định, không áp dụng máy móc quy tắc “luôn nhúng” hoặc “luôn tham chiếu”.

BSON và kiểu dữ liệu

BSON và kiểu dữ liệu giải thích representation (cách biểu diễn) mà MongoDB dùng khi lưu và truyền document. BSON là viết tắt của Binary JSON: nó giữ cấu trúc giống JSON nhưng hỗ trợ thêm kiểu dữ liệu và thông tin kích thước để driver xử lý chính xác hơn.

Ví dụ, catalog sản phẩm có thể lưu giá tiền dưới dạng Decimal128 thay vì số thực thông thường:

db.products.insertOne({
  sku: "MUG-001",
  price: Decimal128("12.50"),
  available: true,
  tags: ["drinkware", "gift"],
  releasedAt: ISODate("2025-01-15T00:00:00Z")
})

Một số lựa chọn quan trọng:

Mongosh hiển thị các hàm tiện ích (helper) như ObjectId(), Decimal128() và ISODate(). Đây là cú pháp JavaScript của shell để tạo giá trị BSON; document trên không phải JSON thuần túy. Ranh giới này quan trọng khi dữ liệu đi qua API trả JSON, nơi JSON không có biểu diễn chuẩn cho ObjectId hoặc Decimal128.

Một gotcha phổ biến là phân biệt field có giá trị null với field không tồn tại. Điều kiện { field: null } có thể khớp cả hai trường hợp. Nếu hai trạng thái có ý nghĩa khác nhau trong nghiệp vụ, hãy dùng thêm $exists và đặt quy ước rõ ràng.

Kiến trúc MongoDB

Kiến trúc MongoDB nối mô hình logic với cách triển khai thật. mongod là tiến trình máy chủ MongoDB. Ứng dụng thường kết nối đến một mongod đơn lẻ trong môi trường học, hoặc đến một replica set/sharded cluster trong môi trường production.

• Standalone là một mongod độc lập. Nó dễ cài và phù hợp để học, nhưng không tự có failover (chuyển sang tiến trình dự phòng) nếu máy chủ hỏng.
• Replica set là một nhóm các mongod duy trì nhiều bản sao dữ liệu. Primary nhận ghi, secondary sao chép dữ liệu và một cuộc election (bầu chọn primary) có thể chọn primary mới khi cần. Bản sao giúp tăng tính sẵn sàng, nhưng không thay thế backup.
• Sharded cluster phân phối dữ liệu trên nhiều shard để mở rộng dung lượng hoặc throughput (số thao tác xử lý trong một đơn vị thời gian). Mỗi shard thường là một replica set. mongos là query router (bộ định tuyến truy vấn) nhận request và định tuyến tới shard phù hợp; config server giữ metadata (siêu dữ liệu) của cluster.

Đường đi tối giản của một lượt đọc có thể là:

Ứng dụng
   │
   ▼
Driver ──────► mongod (standalone hoặc replica set)
   │
   └─────────► mongos ──────► các shard trong sharded cluster

Trade-off nằm ở độ phức tạp vận hành. Standalone ít thành phần nhưng có điểm lỗi đơn. Replica set cần theo dõi election, replication lag (độ trễ sao chép) và cách driver phản ứng khi topology thay đổi. Sharded cluster có thêm shard key, metadata và khả năng request phải đi tới nhiều shard. Đừng chọn sharding chỉ vì dữ liệu “có thể lớn”; trước hết hãy đo workload và kiểm tra giới hạn của một replica set.

MongoDB và cơ sở dữ liệu SQL

MongoDB và cơ sở dữ liệu SQL không nhằm tìm một bên “tốt hơn”. Mục tiêu là nhận ra giả định của từng mô hình để chọn đúng cho workload.

Ví dụ đơn hàng ở trên thường phù hợp với MongoDB nếu màn hình chi tiết luôn đọc đơn hàng cùng các items. Ngược lại, nếu nhiều quy trình độc lập cập nhật cùng một danh mục sản phẩm, cần constraint (ràng buộc) quan hệ chặt và nhiều báo cáo join ad-hoc (truy vấn phát sinh linh hoạt, không có mẫu cố định), mô hình SQL có thể tự nhiên hơn. MongoDB vẫn có transaction và join-like operation (thao tác kết hợp dữ liệu giữa các collection), nhưng dùng chúng không miễn phí: chúng có chi phí về độ phức tạp, latency (độ trễ) hoặc cách thiết kế.

Lộ trình đọc đề xuất

Thứ tự dưới đây đi từ khái niệm tổng quát đến quyết định triển khai. Cột cuối là bằng chứng bạn nên có trước khi chuyển bài.

Bẫy thường gặp và nguyên tắc thực hành

Nói ngắn gọn: hãy thiết kế theo cách dữ liệu được sử dụng, kiểm tra kiểu dữ liệu ở biên, và tách rõ high availability (tính sẵn sàng cao), backup (khả năng quay lại trạng thái cũ) và scaling (mở rộng tải).

Toàn bộ bài trong phần

Dùng các thẻ dưới đây để mở trực tiếp từng bài. Đây là danh sách đầy đủ của phần Nền tảng MongoDB:

Bước tiếp theo trong lộ trình

Sau khi hoàn thành năm bài, hãy chuyển từ “MongoDB lưu gì?” sang “ứng dụng thao tác dữ liệu đó thế nào?”. Các trang sau dùng trực tiếp mô hình document và topology bạn vừa học: