Hướng dẫn mongodb best practices - các phương pháp hay nhất mongodb

Bạn đã bao giờ tự hỏi, "Làm thế nào để tôi mô hình hóa một lược đồ cho ứng dụng của tôi?" Đó là một trong những câu hỏi phổ biến nhất mà các nhà phát triển có liên quan đến MongoDB. Và câu trả lời là, nó phụ thuộc. Điều này là do cơ sở dữ liệu tài liệu có từ vựng phong phú có khả năng thể hiện các mối quan hệ dữ liệu theo những cách nhiều sắc thái hơn SQL. Có rất nhiều điều cần xem xét khi chọn một lược đồ. Ứng dụng của bạn có đọc hay viết nặng không? Dữ liệu nào thường được truy cập cùng nhau? Cân nhắc hiệu suất của bạn là gì? Làm thế nào dữ liệu của bạn sẽ tăng trưởng và quy mô?it depends. This is because document databases have a rich vocabulary that is capable of expressing data relationships in more nuanced ways than SQL. There are many things to consider when picking a schema. Is your app read or write heavy? What data is frequently accessed together? What are your performance considerations? How will your data set grow and scale?

Trong bài đăng này, chúng tôi sẽ thảo luận về những điều cơ bản của mô hình dữ liệu bằng các ví dụ trong thế giới thực. Bạn sẽ tìm hiểu các phương pháp và từ vựng chung mà bạn có thể sử dụng khi thiết kế lược đồ cơ sở dữ liệu cho ứng dụng của mình.

Được rồi, trước hết, bạn có biết rằng thiết kế lược đồ MongoDB thích hợp là phần quan trọng nhất trong việc triển khai cơ sở dữ liệu có thể mở rộng, nhanh chóng và giá cả phải chăng? Đó là sự thật, và thiết kế lược đồ thường là một trong những khía cạnh bị bỏ qua nhất của chính quyền MongoDB. Tại sao thiết kế lược đồ MongoDB lại quan trọng như vậy? Vâng, có một vài lý do chính đáng. Theo kinh nghiệm của tôi, hầu hết mọi người đến MongoDB đều có xu hướng nghĩ về thiết kế lược đồ MongoDB giống như thiết kế lược đồ quan hệ di sản, điều này không cho phép bạn tận dụng tối đa tất cả các cơ sở dữ liệu MongoDB đó. Đầu tiên, chúng ta hãy xem thiết kế cơ sở dữ liệu quan hệ di sản so với thiết kế lược đồ MongoDB.

Phương pháp tiếp cận thiết kế lược đồ - Quan hệ so với & NBSP; MongoDB

Khi nói đến thiết kế lược đồ cơ sở dữ liệu MongoDB, đây là điều mà hầu hết các nhà phát triển nghĩ đến khi họ đang xem xét thiết kế một lược đồ quan hệ và lược đồ MongoDB.

Tôi phải thừa nhận rằng tôi hiểu sự thúc đẩy để thiết kế lược đồ MongoDB của bạn giống như cách bạn luôn thiết kế lược đồ SQL của bạn. Hoàn toàn bình thường khi muốn chia dữ liệu của bạn thành các bảng nhỏ gọn như bạn vẫn luôn làm trước đây. Tôi đã phạm tội khi làm điều này khi lần đầu tiên tôi bắt đầu học cách sử dụng MongoDB. Tuy nhiên, như chúng ta sẽ sớm thấy, bạn mất đi nhiều tính năng tuyệt vời của MongoDB khi bạn thiết kế lược đồ của mình như lược đồ SQL.

Và đây là cách mà điều đó làm cho tôi cảm thấy.

Tuy nhiên, tôi nghĩ rằng tốt nhất là so sánh thiết kế lược đồ MongoDB với thiết kế lược đồ quan hệ vì đó là nơi mà nhiều nhà phát triển đến MongoDB đến từ. Vì vậy, hãy xem hai mẫu thiết kế này khác nhau như thế nào.

Thiết kế lược đồ quan hệ

Khi thiết kế một lược đồ quan hệ, thông thường, các Dev mô hình lược đồ của họ độc lập với các truy vấn. Họ tự hỏi, "Tôi có dữ liệu gì?" Sau đó, bằng cách sử dụng các phương pháp theo quy định, chúng sẽ bình thường hóa (thường ở dạng bình thường thứ 3). TL; DR của chuẩn hóa là chia dữ liệu của bạn thành các bảng, do đó bạn không sao chép dữ liệu. Chúng ta hãy xem một ví dụ về cách bạn sẽ mô hình hóa một số dữ liệu người dùng trong cơ sở dữ liệu quan hệ.normalize (typically in 3rd normal form). The tl;dr of normalization is to split up your data into tables, so you don't duplicate data. Let's take a look at an example of how you would model some user data in a relational database.

Trong ví dụ này, bạn có thể thấy rằng dữ liệu người dùng được chia thành các bảng riêng biệt và nó có thể được kết hợp với nhau bằng các khóa nước ngoài trong cột user_id của bảng nghề nghiệp và xe hơi. Bây giờ, chúng ta hãy xem cách chúng ta có thể mô hình hóa dữ liệu tương tự trong MongoDB.user_id column of the Professions and Cars table. Now, let's take a look at how we might model this same data in MongoDB.

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

Bây giờ, thiết kế lược đồ MongoDB hoạt động khác rất nhiều so với thiết kế lược đồ quan hệ. Với thiết kế lược đồ MongoDB, có:

Khi bạn đang thiết kế thiết kế lược đồ MongoDB của mình, điều duy nhất quan trọng là bạn thiết kế một lược đồ sẽ hoạt động tốt cho ứng dụng của bạn. Hai ứng dụng khác nhau sử dụng cùng một dữ liệu chính xác có thể có các lược đồ rất khác nhau nếu các ứng dụng được sử dụng khác nhau. Khi thiết kế một lược đồ, chúng tôi muốn xem xét như sau:your application. Two different apps that use the same exact data might have very different schemas if the applications are used differently. When designing a schema, we want to take into consideration the following:

• Cung cấp hiệu suất truy vấn tốt

• Yêu cầu số lượng phần cứng hợp lý

Chúng ta hãy xem cách chúng ta có thể mô hình hóa mô hình người dùng quan hệ trong MongoDB.

Bạn có thể thấy rằng thay vì chia dữ liệu của chúng tôi thành các bộ sưu tập hoặc tài liệu riêng biệt, chúng tôi tận dụng thiết kế dựa trên tài liệu của MongoDB để nhúng dữ liệu vào các mảng và đối tượng trong đối tượng người dùng. Bây giờ chúng tôi có thể thực hiện một truy vấn đơn giản để kéo tất cả dữ liệu đó lại với nhau cho ứng dụng của chúng tôi.

Nhúng so với & nbsp; tham chiếu

Thiết kế lược đồ MongoDB thực sự chỉ có hai lựa chọn cho mỗi phần dữ liệu. Bạn có thể nhúng dữ liệu đó trực tiếp hoặc tham chiếu một phần dữ liệu khác bằng toán tử tra cứu $ (tương tự như tham gia). Hãy xem xét những ưu và nhược điểm của việc sử dụng từng tùy chọn trong lược đồ của bạn.$lookup operator (similar to a JOIN). Let's look at the pros and cons of using each option in your schema.

Nhúng

Thuận lợi

• Bạn có thể truy xuất tất cả các thông tin liên quan trong một truy vấn duy nhất.

• Tránh thực hiện các tham gia trong mã ứng dụng hoặc sử dụng $ Tra cứu.$lookup.

• Tuy nhiên, nếu bạn cần một giao dịch trên nhiều hoạt động, bạn có thể sử dụng toán tử giao dịch.transaction operator.

Giới hạn

• Các tài liệu lớn có nghĩa là chi phí cao hơn nếu hầu hết các trường không liên quan. Bạn có thể tăng hiệu suất truy vấn bằng cách giới hạn kích thước của các tài liệu mà bạn đang gửi qua dây cho mỗi truy vấn.

Tham khảo

Được rồi, do đó, tùy chọn khác để thiết kế lược đồ của chúng tôi đang tham khảo một tài liệu khác bằng ID đối tượng độc đáo của tài liệu và kết nối chúng lại với nhau bằng toán tử tra cứu $. Tham chiếu hoạt động tương tự như toán tử tham gia trong truy vấn SQL. Nó cho phép chúng tôi phân chia dữ liệu để thực hiện các truy vấn hiệu quả và có thể mở rộng hơn, nhưng vẫn duy trì mối quan hệ giữa dữ liệu.unique object ID and connecting them together using the $lookup operator. Referencing works similarly as the JOIN operator in an SQL query. It allows us to split up data to make more efficient and scalable queries, yet maintain relationships between data.

Thuận lợi

• Bằng cách chia dữ liệu, bạn sẽ có các tài liệu nhỏ hơn.

• Không thường xuyên truy cập thông tin không cần thiết trên mỗi truy vấn.

• Giảm số lượng sao chép dữ liệu. Tuy nhiên, điều quan trọng cần lưu ý là không nên tránh sao chép dữ liệu nếu nó dẫn đến một lược đồ tốt hơn.

Giới hạn

• Để truy xuất tất cả các dữ liệu trong các tài liệu được tham chiếu, tối thiểu hai truy vấn hoặc tra cứu $ cần thiết để truy xuất tất cả các thông tin.$lookup required to retrieve all the information.

Loại mối quan hệ

Được rồi, vì vậy bây giờ chúng tôi đã khám phá hai cách chúng tôi có thể phân chia dữ liệu khi thiết kế các lược đồ của chúng tôi trong MongoDB, hãy xem xét các mối quan hệ phổ biến mà bạn có thể quen thuộc với mô hình nếu bạn đến từ nền SQL. Chúng tôi sẽ bắt đầu với các mối quan hệ đơn giản hơn và làm việc theo cách của chúng tôi đến một số mô hình và mối quan hệ thú vị và cách chúng tôi mô hình hóa chúng bằng các ví dụ trong thế giới thực. Lưu ý, chúng tôi chỉ sẽ cào lên bề mặt của các mối quan hệ mô hình hóa ở MongoDB ở đây.

Điều quan trọng cần lưu ý là ngay cả khi ứng dụng của bạn có cùng dữ liệu chính xác như các ví dụ được liệt kê dưới đây, bạn có thể có một lược đồ hoàn toàn khác so với mức tôi đã nêu ở đây. Điều này là do sự cân nhắc quan trọng nhất mà bạn thực hiện cho lược đồ của bạn là cách mà dữ liệu của bạn sẽ được hệ thống của bạn sử dụng. Trong mỗi ví dụ, tôi sẽ phác thảo các yêu cầu cho mỗi ứng dụng và tại sao một lược đồ nhất định được sử dụng cho ví dụ đó. Nếu bạn muốn thảo luận về các chi tiết cụ thể của lược đồ của bạn, hãy chắc chắn mở một cuộc trò chuyện trên Diễn đàn Cộng đồng MongoDB và tất cả chúng ta đều có thể thảo luận về những gì sẽ hoạt động tốt nhất cho ứng dụng độc đáo của bạn.MongoDB Community Forum, and we all can discuss what will work best for your unique application.

One-to-One

Hãy xem tài liệu người dùng của chúng tôi. Ví dụ này có một số dữ liệu một-một tuyệt vời trong đó. Ví dụ: trong hệ thống của chúng tôi, một người dùng chỉ có thể có một tên. Vì vậy, đây sẽ là một ví dụ về mối quan hệ một-một. Chúng tôi có thể mô hình hóa tất cả dữ liệu một-một dưới dạng các cặp giá trị khóa trong cơ sở dữ liệu của chúng tôi.

• Thích cặp giá trị khóa được nhúng trong tài liệu.

• Ví dụ: & nbsp; một nhân viên có thể làm việc trong một và chỉ một bộ phận.

One-to-Few

Được rồi, bây giờ chúng ta hãy nói rằng chúng ta đang xử lý một chuỗi nhỏ dữ liệu được liên kết với người dùng của chúng ta. Ví dụ: chúng ta có thể cần lưu trữ một số địa chỉ được liên kết với một người dùng nhất định. Không có khả năng người dùng cho ứng dụng của chúng tôi sẽ có nhiều hơn một vài địa chỉ khác nhau. Đối với các mối quan hệ như thế này, chúng tôi sẽ định nghĩa đây là mối quan hệ một người.one-to-few relationship.

Hãy nhớ rằng khi tôi nói với bạn rằng không có quy tắc nào đối với thiết kế lược đồ MongoDB? Vâng, tôi đã nói dối. Tôi đã tạo ra một vài quy tắc tiện dụng để giúp bạn thiết kế lược đồ cho ứng dụng của bạn.

Quy tắc 1: Lợi thích nhúng trừ khi có một lý do thuyết phục không.: Favor embedding unless there is a compelling reason not to.

Nói chung, hành động mặc định của tôi là nhúng dữ liệu trong một tài liệu. Tôi kéo nó ra và chỉ tham khảo nó nếu tôi cần tự mình truy cập, nó quá lớn, tôi hiếm khi cần nó, hoặc bất kỳ lý do nào khác.

• Thích nhúng cho các mối quan hệ một-few.

One-to-Many

Được rồi, giả sử rằng bạn đang xây dựng một trang sản phẩm cho một trang web thương mại điện tử và bạn sẽ phải thiết kế một lược đồ có thể hiển thị thông tin sản phẩm. Trong hệ thống của chúng tôi, chúng tôi lưu thông tin về tất cả nhiều phần tạo nên từng sản phẩm cho các dịch vụ sửa chữa. Làm thế nào bạn sẽ thiết kế một lược đồ để lưu tất cả dữ liệu này, nhưng vẫn làm cho trang sản phẩm của bạn hoạt động? Bạn có thể muốn xem xét một lược đồ một-nhiều vì một sản phẩm của bạn được tạo thành từ nhiều phần.one-to-many schema since your one product is made up of many parts.

Bây giờ, với một lược đồ có khả năng tiết kiệm hàng ngàn bộ phận phụ, có lẽ chúng ta không cần phải có tất cả dữ liệu cho các bộ phận trên mỗi yêu cầu, nhưng điều quan trọng là mối quan hệ này được duy trì trong lược đồ của chúng ta. Vì vậy, chúng tôi có thể có một bộ sưu tập sản phẩm với dữ liệu về từng sản phẩm trong cửa hàng thương mại điện tử của chúng tôi và để giữ cho dữ liệu phần đó được liên kết, chúng tôi có thể giữ một mảng ID đối tượng liên kết với tài liệu có thông tin về bộ phận. Những bộ phận này có thể được lưu trong cùng một bộ sưu tập hoặc trong một bộ sưu tập riêng biệt, nếu cần. Chúng ta hãy xem cái này trông như thế nào.

Quy tắc 2: Cần phải tự mình truy cập một đối tượng là một lý do thuyết phục để không nhúng nó.: Needing to access an object on its own is a compelling reason not to embed it.

Quy tắc 3: Tránh tham gia/tra cứu nếu có thể, nhưng đừng sợ nếu chúng có thể cung cấp thiết kế lược đồ tốt hơn.: Avoid joins/lookups if possible, but don't be afraid if they can provide a better schema design.

One-to-Squillions

Điều gì sẽ xảy ra nếu chúng ta có một lược đồ nơi có khả năng có hàng triệu người phụ, hoặc nhiều hơn? Đó là khi chúng ta đạt được lược đồ một-sau. Và, tôi biết bạn đang nghĩ gì: _is squillions một từ thực sự? _ Và câu trả lời là có, đó là một từ thực sự.And the answer is yes, it is a real word.

Hãy tưởng tượng rằng bạn đã được yêu cầu tạo một ứng dụng ghi nhật ký máy chủ. Mỗi máy chủ có khả năng tiết kiệm một lượng lớn dữ liệu, tùy thuộc vào mức độ dài dòng bạn đang đăng nhập và thời gian bạn lưu trữ nhật ký máy chủ.

Với MongoDB, việc theo dõi dữ liệu trong một mảng không bị ràng buộc là nguy hiểm, vì chúng tôi có khả năng đạt giới hạn 16 MB mỗi tài liệu đó. Bất kỳ máy chủ nhất định nào cũng có thể tạo đủ tin nhắn để tràn kích thước tài liệu 16 MB, ngay cả khi chỉ có các ObjectID được lưu trữ trong một mảng. Vì vậy, chúng ta cần suy nghĩ lại về cách chúng ta có thể theo dõi mối quan hệ này mà không phải chống lại bất kỳ giới hạn khó khăn nào.

Vì vậy, thay vì theo dõi mối quan hệ giữa máy chủ và thông báo nhật ký trong tài liệu máy chủ, hãy để mỗi tin nhắn nhật ký lưu trữ máy chủ mà thông báo của nó được liên kết. Bằng cách lưu trữ dữ liệu trong nhật ký, chúng tôi không còn cần phải lo lắng về một mảng không giới hạn với ứng dụng của chúng tôi! Chúng ta hãy xem làm thế nào điều này có thể hoạt động.

Quy tắc 4: Mảng không nên phát triển mà không bị ràng buộc. Nếu có hơn một vài trăm tài liệu ở phía "nhiều", đừng nhúng chúng; Nếu có hơn một vài nghìn tài liệu ở phía "nhiều", đừng sử dụng một loạt các tài liệu tham khảo ObjectID. Mảng cao cấp là một lý do thuyết phục để không nhúng.: Arrays should not grow without bound. If there are more than a couple of hundred documents on the "many" side, don't embed them; if there are more than a few thousand documents on the "many" side, don't use an array of ObjectID references. High-cardinality arrays are a compelling reason not to embed.

Many-to-Many

Mô hình thiết kế lược đồ cuối cùng mà chúng ta sẽ đề cập trong bài đăng này là mối quan hệ nhiều đến nhiều. Đây là một mẫu lược đồ rất phổ biến khác mà chúng ta thấy tất cả thời gian trong các thiết kế lược đồ quan hệ và MongoDB. Đối với mô hình này, chúng ta hãy tưởng tượng rằng chúng ta đang xây dựng một ứng dụng cần làm. Trong ứng dụng của chúng tôi, người dùng có thể có nhiều tác vụ và một tác vụ có thể có nhiều người dùng được gán cho nó.many-to-many relationship. This is another very common schema pattern that we see all the time in relational and MongoDB schema designs. For this pattern, let's imagine that we are building a to-do application. In our app, a user may have many tasks and a task may have many users assigned to it.

Để duy trì các mối quan hệ này giữa người dùng và tác vụ, sẽ cần phải có các tài liệu tham khảo từ một người dùng đến nhiều tác vụ và tài liệu tham khảo từ một nhiệm vụ đến nhiều người dùng. Hãy xem cách điều này có thể hoạt động cho một ứng dụng danh sách việc cần làm.one user to the many tasks and references from the one task to the many users. Let's look at how this could work for a to-do list application.

Từ ví dụ này, bạn có thể thấy rằng mỗi người dùng có một phần phụ của các tác vụ được liên kết và mỗi tác vụ có một phần phụ của chủ sở hữu cho mỗi mục trong ứng dụng việc cần làm của chúng tôi.

Bản tóm tắt

Như bạn có thể thấy, có rất nhiều cách khác nhau để thể hiện thiết kế lược đồ của bạn, bằng cách vượt ra ngoài việc bình thường hóa dữ liệu của bạn giống như bạn có thể đã làm trong SQL. Bằng cách tận dụng dữ liệu nhúng trong tài liệu hoặc tham chiếu các tài liệu bằng toán tử Tra cứu $, bạn có thể thực hiện một số truy vấn cơ sở dữ liệu thực sự mạnh mẽ, có thể mở rộng và hiệu quả hoàn toàn duy nhất cho ứng dụng của bạn. Trên thực tế, chúng tôi chỉ có thể làm trầy xước bề mặt của tất cả các cách mà bạn có thể mô hình hóa dữ liệu của mình bằng MongoDB. Nếu bạn muốn tìm hiểu thêm về Thiết kế lược đồ MongoDB, hãy chắc chắn kiểm tra chuỗi tiếp tục của chúng tôi về thiết kế lược đồ trong MongoDB:

Tôi muốn kết thúc bài đăng này với quy tắc quan trọng nhất đối với thiết kế lược đồ MongoDB.

Quy tắc 5: Như mọi khi, với MongoDB, cách bạn mô hình hóa dữ liệu của mình phụ thuộc - hoàn toàn - vào các mẫu truy cập dữ liệu của ứng dụng cụ thể của bạn. Bạn muốn cấu trúc dữ liệu của mình để phù hợp với các cách mà các truy vấn ứng dụng của bạn và cập nhật nó.: As always, with MongoDB, how you model your data depends – entirely – on your particular application's data access patterns. You want to structure your data to match the ways that your application queries and updates it.

Hãy nhớ rằng, mọi ứng dụng đều có nhu cầu và yêu cầu duy nhất, vì vậy thiết kế lược đồ sẽ phản ánh nhu cầu của ứng dụng cụ thể đó. Lấy các ví dụ được liệt kê trong bài đăng này làm điểm khởi đầu cho ứng dụng của bạn. Suy ngẫm về những gì bạn cần làm và cách bạn có thể sử dụng lược đồ của mình để giúp bạn đạt được điều đó.

• Một-một-thích các cặp giá trị khóa trong tài liệu - Prefer key value pairs within the document

• Một-to-few-thích nhúng - Prefer embedding

• Một-nhiều-thích nhúng - Prefer embedding

• Một lần nữa-thích tham khảo - Prefer Referencing

• Nhiều-nhiều-thích tham khảo - Prefer Referencing

Các quy tắc chung cho thiết kế lược đồ MongoDB:

• Quy tắc 1: Lợi thích nhúng trừ khi có một lý do thuyết phục không.: Favor embedding unless there is a compelling reason not to.

• Quy tắc 2: Cần phải tự mình truy cập một đối tượng là một lý do thuyết phục để không nhúng nó.: Needing to access an object on its own is a compelling reason not to embed it.

• Quy tắc 3: Tránh tham gia và tra cứu nếu có thể, nhưng đừng sợ nếu chúng có thể cung cấp một thiết kế lược đồ tốt hơn.: Avoid joins and lookups if possible, but don't be afraid if they can provide a better schema design.

• Quy tắc 4: Mảng không nên phát triển mà không bị ràng buộc. Nếu có hơn một vài trăm tài liệu ở nhiều bên, đừng nhúng chúng; Nếu có hơn một vài nghìn tài liệu ở nhiều bên, đừng sử dụng một loạt các tài liệu tham khảo ObjectID. Mảng cao cấp là một lý do thuyết phục để không nhúng.: Arrays should not grow without bound. If there are more than a couple of hundred documents on the many side, don't embed them; if there are more than a few thousand documents on the many side, don't use an array of ObjectID references. High-cardinality arrays are a compelling reason not to embed.

• Quy tắc 5: Như mọi khi, với MongoDB, cách bạn mô hình hóa dữ liệu của mình phụ thuộc hoàn toàn vào các mẫu truy cập dữ liệu của ứng dụng cụ thể của bạn. Bạn muốn cấu trúc dữ liệu của mình để phù hợp với các cách mà các truy vấn ứng dụng của bạn và cập nhật nó.: As always, with MongoDB, how you model your data depends entirely on your particular application's data access patterns. You want to structure your data to match the ways that your application queries and updates it.

Chúng tôi chỉ làm trầy xước bề mặt của các mẫu thiết kế trong MongoDB. Trên thực tế, chúng tôi thậm chí chưa bắt đầu bắt đầu khám phá các mẫu thậm chí không thể thực hiện từ xa trong một mô hình quan hệ di sản. Nếu bạn muốn tìm hiểu thêm về các mẫu này, hãy kiểm tra các tài nguyên bên dưới.

Tài nguyên bổ sung: