Các mẫu thiết kế MongoDB

Sử dụng cơ sở dữ liệu NoSQL hơi khác so với sử dụng cơ sở dữ liệu quan hệ chính như PostgreSQL. Bạn có nhiều tự do hơn trong việc lập mô hình dữ liệu cho các tài liệu của mình vì mỗi tài liệu của một bộ sưu tập có thể chứa các thuộc tính đa dạng. Trong các dự án lớn hơn, lợi thế này có thể dẫn đến việc tạo ra một chút lộn xộn trong dữ liệu của bạn. Chẳng hạn như trong trường hợp lập trình, các mẫu thiết kế có thể giúp bạn tổ chức các mối quan hệ giữa tài liệu và bộ sưu tập. Có nhiều mẫu mà bạn có thể chọn trong quá trình lập mô hình dữ liệu trong MongoDB, nhưng trong bài viết này, bạn sẽ biết về ba mẫu trong số đó

Mẫu thuộc tính

Khi bạn có nhiều tài liệu hầu hết có cùng thuộc tính, nhưng chúng cũng có các thuộc tính cụ thể của chúng, mẫu này có thể hữu ích cho bạn. Tất cả những gì bạn cần làm là tạo một thuộc tính mảng cho tất cả các đặc điểm này và đưa chúng vào làm đối tượng khóa-giá trị. Giải pháp này sẽ cho phép bạn sắp xếp và tìm kiếm tài liệu một cách dễ dàng hơn và nó sẽ cải thiện hiệu suất. Bạn có thể sử dụng nó, ví dụ. , trong một dự án thương mại điện tử nơi bạn có rất nhiều sản phẩm tương tự

ba mẫu

Loại mẫu này, như tên cho thấy, tạo ra một cây phụ thuộc giữa các tài liệu của một bộ sưu tập. Có một số cách tiếp cận để tạo một cây, nhưng cách dễ nhất là thêm các thuộc tính có tham chiếu đến cha và con của tài liệu. Mẫu thiết kế này sẽ hữu ích ở mọi nơi có cấu trúc dữ liệu phân cấp, ví dụ:. , sự phụ thuộc giữa các nhân viên trong một tổ chức

Mẫu tham chiếu mở rộng

Cuối cùng nhưng không kém phần quan trọng, mẫu thiết kế có thể cải thiện hiệu suất của ứng dụng nếu bạn thường xuyên thực hiện các thao tác THAM GIA trên tài liệu của mình. Để giảm bớt chúng, bạn cần nhúng các thuộc tính cần thiết nhất của tài liệu của bộ sưu tập thứ hai vào tài liệu của bộ sưu tập thứ nhất. Bằng cách này, bạn sẽ không phải thực hiện các thao tác THAM GIA thường xuyên và nếu bạn cần thêm các thuộc tính của tài liệu của bộ sưu tập thứ hai, bạn luôn có quyền truy cập để lấy chúng

​

Tóm lược

Tóm lại, ba mẫu này, tôi đã mô tả ngắn gọn, có thể cải thiện việc tổ chức cấu trúc dữ liệu của bạn và tối ưu hóa hiệu suất ứng dụng của bạn. Tôi khuyến khích bạn đọc tài liệu MongoDB để biết thêm. Nếu bạn muốn khám phá thêm các mẫu thiết kế, tôi khuyên bạn nên tham gia khóa học mô hình hóa dữ liệu trên trường đại học MongoDB

Các mẫu lược đồ rất giống với Mẫu thiết kế [Gang of Four] nhưng tập trung vào việc thiết kế lược đồ. Đây là một số khối xây dựng được các nhà phát triển xác định sau nhiều năm kinh nghiệm giúp thiết kế lược đồ của các bảng/bộ sưu tập theo cách sao cho ứng dụng trở nên có khả năng mở rộng hơn về mặt đọc/ghi

Không có mẫu lược đồ hoàn hảo. Đây chỉ là những hướng dẫn và một số tiêu chuẩn ngành mà bạn có thể tuân theo để xây dựng một lược đồ tốt hơn

Bạn có thể xác định mẫu lược đồ của riêng mình dựa trên trường hợp sử dụng ứng dụng của bạn

Bạn cũng có thể sử dụng nhiều mẫu lược đồ cùng nhau để giải quyết một trường hợp sử dụng cụ thể

Để tôi nhắc lại điều này một lần nữa, không có mẫu nào có thể được áp dụng như plug and play. Bạn cần sửa đổi nó để phù hợp với trường hợp sử dụng của mình

Các mẫu lược đồ không giới hạn ở một cơ sở dữ liệu cụ thể, nó phổ biến cho tất cả chúng nhưng với mục đích của bài viết, hầu hết các ví dụ và lược đồ được xác định bằng MongoDB

Trước khi thiết kế bất kỳ lược đồ nào, bạn cần ước tính những điều dưới đây

1. Quy mô nó có thể mong đợi
2. Cho dù trường hợp sử dụng là Viết hay Đọc chuyên sâu
3. Chi phí trên cơ sở dữ liệu

Chúng tôi sẽ thảo luận về từng mẫu với các ví dụ về cơ sở dữ liệu phim [Ai không thích phim?]

Bạn có thể đang sử dụng rất nhiều các mẫu này đã có trong ứng dụng của mình nhưng thật tốt khi biết từ vựng của các mẫu/thiết kế lược đồ này

Chúng ta có thể phân loại các mẫu thành 3 loại

1. đại diện
2. Tần suất truy cập
3. nhóm

Mẫu đại diện

Các mẫu này tập trung nhiều hơn vào việc biểu diễn lược đồ

Mẫu thuộc tính

Mẫu lập phiên bản tài liệu

Mô hình đa hình

Các mẫu thuộc tính rất phù hợp với các tập hợp/bảng có tập hợp con các trường tương tự và bạn đang truy vấn trên các tập hợp con này

Giả sử chúng ta có một bộ phim được phát hành ở các quốc gia khác nhau và vào các ngày khác nhau

Nhược điểm của lược đồ trên là giả sử bạn muốn lọc tất cả các phim phát hành ở Ấn Độ có ngày phát hành lớn hơn một ngày cụ thể. Trong trường hợp này, bạn sẽ cần tạo chỉ mục trên release_india và nếu bạn có bộ lọc trên Dubai thì bạn sẽ phải tạo chỉ mục trên release_dubai.
Hãy sửa đổi lược đồ thành một trường duy nhất releases

Bây giờ chúng tôi đã sửa đổi lược đồ theo cách sao cho tất cả các bản phát hành đều thuộc một trường và chúng tôi có thể tạo một chỉ mục trên các bản phát hành nhưng điều đó là sai bởi vì khi bạn tạo một chỉ mục trên các bản phát hành, MongoDB sẽ tạo các chỉ mục nội bộ trên tất cả các trường con. Bây giờ, hãy sửa đổi lược đồ và làm cho nó tổng quát hơn

Đối với những điều trên, bạn chỉ cần một chỉ mục releases.country dễ quản lý và dễ dàng hơn. Bây giờ chúng tôi cũng đã xác định các thuộc tính của bản phát hành tôi. e, date và country. Đây là tất cả những gì về mẫu thuộc tính. Bạn cần xác định lược đồ sao cho có thể nhóm các trường tương tự thành một trường có một số thuộc tính chung

2. Mẫu lập phiên bản tài liệu

Như tên gợi ý, chúng tôi lưu trữ các phiên bản của tài liệu nhưng làm thế nào để chúng tôi thực hiện điều đó một cách hiệu quả và tại sao chúng tôi muốn lưu trữ các phiên bản?

Chúng ta làm điều đó như thế nào?

Ở đây, như bạn có thể thấy, chúng tôi đã sửa đổi available_languages. Vì vậy, bây giờ phiên bản mới hơn của tài liệu được đánh dấu bằng giá trị sửa đổi mới

Nhưng vấn đề là khi bạn truy xuất tài liệu mới nhất, bạn có thể phải sắp xếp dựa trên phiên bản và lấy tài liệu mới nhất, điều này sẽ ảnh hưởng đến hiệu suất của bạn và tiêu tốn nhiều RAM, đồng thời _id cũng bị thay đổi, điều này có thể gây ra nhiều sự cố

Vì vậy, để tránh điều này, chúng tôi tạo một bảng mới để ghi lại các phiên bản và giữ phiên bản mới nhất trong bảng gốc. Đối với phân tích và các mục đích khác, chúng ta có thể sử dụng bảng nhật ký

Ưu điểm của mẫu này về cơ bản là bạn đang sử dụng hai bảng nên sẽ có ít tài liệu hơn trong bộ sưu tập ban đầu, điều này sẽ giúp ích cho hiệu suất đọc và việc đồng bộ hóa với bộ sưu tập nhật ký có thể được thực hiện không đồng bộ, điều này sẽ giúp giảm thời gian phản hồi

Những nhược điểm nằm ở việc viết thành nhiều bộ sưu tập và sự không nhất quán khi chúng ta phải duy trì hai bộ sưu tập

3. mô hình đa hình

Mẫu này được sử dụng khi chúng tôi có các tài liệu có nhiều điểm tương đồng hơn là khác biệt. Trong những trường hợp như vậy, sẽ tốt hơn nếu chúng tôi có thể chứa tất cả các tài liệu đó trong một bộ sưu tập

Ví dụ: Hãy xem xét bộ sưu tập release_india0 trong cơ sở dữ liệu phim. Hồ sơ có thể là của đạo diễn, diễn viên, nữ diễn viên và các kỹ thuật viên khác. Vì vậy, thay vì tạo các bộ sưu tập riêng biệt cho từng danh mục, chúng tôi cố gắng giữ tất cả chúng trong một bộ sưu tập vì chúng có nhiều điểm tương đồng [Tên, Tuổi, Số năm kinh nghiệm] hơn là khác biệt [Album riêng dành cho nhạc sĩ, cấu trúc cơ thể như ngực, chiều cao, cân nặng . Các trường hợp sử dụng có nhiều điểm tương đồng và ít khác biệt hơn sẽ hoàn hảo cho các mẫu đa hình

Mẫu này hoàn toàn phù hợp với MongoDB vì nó không có lược đồ và có thể chứa nhiều cấu hình với các thuộc tính khác nhau

Ưu điểm của các mẫu như vậy là khi chúng tôi muốn truy xuất tất cả các cấu hình, chúng tôi có thể lấy chúng từ một bộ sưu tập thay vì lấy từ nhiều bộ sưu tập và tổng hợp chúng sẽ rất tốn kém

Nhược điểm của mẫu như vậy là lược đồ trở nên rất phức tạp sau một thời gian khi chúng tôi bao gồm nhiều danh mục hồ sơ và việc xác thực loại lược đồ đó sẽ khó xử lý ở phía ứng dụng

Từ những điều trên, chúng ta có thể thấy rằng rất nhiều thuộc tính hoặc trường phổ biến

Các điểm chính cần nhớ

1. Các mẫu lược đồ không giới hạn ở MongoDB
2. Không có mẫu nào là release_india1. Nó cần được điều chỉnh để phù hợp với trường hợp sử dụng của bạn
3. Chúng ta có thể sử dụng kết hợp các mẫu để giải quyết trường hợp sử dụng
4. Có thể có rất nhiều mẫu khác nhưng đây là một số mẫu tiêu chuẩn

Tôi thích các bài viết ngắn nên tôi sẽ kết thúc bài viết này và chúng ta sẽ thảo luận về các mẫu lược đồ nâng cao hơn trong các phần tiếp theo

Hy vọng bài viết này hữu ích. Cảm ơn bạn đã đọc và cho tôi biết bạn nghĩ gì về các mẫu lược đồ trong phần bình luận

Những mẫu mô hình hóa dữ liệu nào thường được tận dụng với MongoDB?

MongoDB có lược đồ không?

Các mẫu thiết kế của cơ sở dữ liệu là gì?

Làm cách nào để viết lược đồ cho MongoDB?