Thiết kế lược đồ MongoDB

Khi MongoDB được giới thiệu cách đây vài năm, một trong những tính năng quan trọng được giới thiệu là khả năng “schemaless” - Điều này có ý nghĩa gì đối với tài liệu của bạn?

Thiết kế lược đồ MongoDB không thực thi bất kỳ lược đồ nào trên các tài liệu được lưu trữ trong bộ sưu tập. Về cơ bản, MongoDB lưu trữ các tài liệu JSON và mỗi tài liệu có thể chứa bất kỳ cấu trúc nào bạn muốn. Hãy xem xét một số ví dụ từ bộ sưu tập "địa chỉ liên hệ" của chúng tôi bên dưới. Đây là một tài liệu mà bạn có thể lưu trữ:

{
  'name':'user1',
  'address':' 1 mountain view',
  'phone': '123-324-3308',
  'SSN':'123-45-7891'
}

Bây giờ tài liệu thứ hai được lưu trữ trong bộ sưu tập có thể có định dạng sau:

{
  'name': ' user2',
  'employeeid': 546789
}

Thật tuyệt là bạn có thể lưu trữ cả hai tài liệu này trong cùng một bộ sưu tập. Tuy nhiên, vấn đề bắt đầu khi bạn cần truy xuất các tài liệu này từ bộ sưu tập. Làm thế nào để bạn biết nếu tài liệu được truy xuất có định dạng 1 hoặc định dạng 2? Bạn có thể kiểm tra xem tài liệu đã truy xuất có chứa trường ‘ssn’ hay không và sau đó đưa ra quyết định. Một tùy chọn khác là lưu trữ loại tài liệu trong chính tài liệu:

{
  'type': xxx,
  'name': ....
  ...
}

Trong cả hai trường hợp này, điều bạn đạt được là chuyển việc thực thi lược đồ từ cơ sở dữ liệu sang ứng dụng -

Luôn luôn có một lược đồ, vấn đề chỉ là nơi nó được triển khai.

Nếu bạn có các chỉ mục phù hợp, nó sẽ giảm bớt vấn đề ở một mức độ nhất định. Nếu phần lớn các truy vấn của bạn là bởi "workerid", bạn biết rằng tài liệu được truy xuất luôn có định dạng thứ hai - tuy nhiên, phần còn lại của mã của bạn không sử dụng chỉ mục này sẽ vẫn gặp sự cố được đề cập ở trên. Ngoài ra, Nếu bạn đang sử dụng ODM như mongoose thì nó đã tự động thực thi một lược đồ cho bạn trên MongoDB.

Có một số ứng dụng được hưởng lợi từ tính linh hoạt này. Một kịch bản mà bạn nghĩ đến là trường hợp lược đồ có một số trường / cột tùy chọn. Trong MongoDB, không bị phạt nếu thiếu một số cột. Mỗi tài liệu chỉ có thể chứa các trường mà nó cần.

Xác thực tài liệu

Bắt đầu từ phiên bản 3.2.x MongoDB hiện hỗ trợ khái niệm xác thực lược đồ bằng cách sử dụng cấu trúc “trình xác thực”. Điều này cung cấp nhiều cấp độ xác thực - vì vậy bạn có thể chọn cấp độ phù hợp với mình. Hành vi mặc định nếu bạn không sử dụng trình xác thực là hành vi sử dụng schemaless trước đó. Thông thường, bạn sẽ tạo “trình xác thực” tại thời điểm tạo bộ sưu tập

db.createCollection( "contacts",
   { validator: { $or:
      [
         { employeeid: { $exists: true }},
         { SSN: { $exists: true } }
      ]
   }
} )

Bộ sưu tập hiện có

Các bộ sưu tập hiện có có thể được cập nhật bằng lệnh ‘collMod’:

db.runCommand( {
  collMod: "contacts”,
  validator: { $or: [ { employeeid: { $exists: true }}, { SSN: { $exists:true} } ] }
} )

Mức xác thực

MongoDB hỗ trợ khái niệm ‘ValidationLevel’. Mức xác thực mặc định là 'nghiêm ngặt' có nghĩa là việc chèn và cập nhật không thành công nếu tài liệu không đáp ứng tiêu chí xác thực. Nếu mức độ xác thực là 'Trung bình', nó sẽ áp dụng xác thực cho các tài liệu hiện có đáp ứng các tiêu chí xác thực. Các tài liệu hiện đang tồn tại và không đáp ứng tiêu chí sẽ không được xác thực. Mặc dù thuận tiện, nhưng mức xác thực 'Trung bình' có thể khiến bạn gặp rắc rối - vì vậy, nó cần được sử dụng cẩn thận.

Hành động xác thực

Theo mặc định, hành động xác thực là 'Lỗi'. Nếu tài liệu của bạn không được xác thực thì đó là lỗi và cập nhật / chèn không thành công. Tuy nhiên, bạn cũng có thể đặt hành động Xác thực thành 'cảnh báo' về cơ bản ghi lại hành động vi phạm lược đồ trong nhật ký, nhưng không thể chèn.

Những ví dụ thiết kế lược đồ nào sẽ giúp bạn trong dự án tiếp theo của mình, hãy cho chúng tôi biết!