Bạn đã bao giờ tự hỏi "Làm cách nào để lập mô hình lược đồ cho ứng dụng của mình chưa?" . Và câu trả lời là, nó phụ thuộc vào. Điều này là do cơ sở dữ liệu tài liệu có vốn từ vựng phong phú có khả năng diễn đạt các mối quan hệ dữ liệu theo nhiều cách sắc thái hơn SQL. Có nhiều điều cần xem xét khi chọn lược đồ. Ứng dụng của bạn đọc hoặc ghi có nặng không? 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 hóa dữ liệu bằng các ví dụ trong thế giới thực. Bạn sẽ học các phương pháp và từ vựng phổ biến 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 phù hợp là phần quan trọng nhất để triển khai cơ sở dữ liệu có thể mở rộng, nhanh chóng và giá cả phải chăng không? . Tại sao Thiết kế lược đồ MongoDB lại quan trọng như vậy? . Theo kinh nghiệm của tôi, hầu hết mọi người đến với MongoDB có xu hướng nghĩ về thiết kế lược đồ MongoDB giống như thiết kế lược đồ quan hệ cũ, điều này không cho phép bạn tận dụng tối đa tất cả những gì cơ sở dữ liệu MongoDB cung cấp. Trước tiên, hãy xem cách thiết kế cơ sở dữ liệu quan hệ kế thừa 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. MongoDBKhi 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ế lược đồ quan hệ và lược đồ MongoDB  Tôi phải thừa nhận rằng tôi hiểu động lực 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 mình. Hoàn toàn bình thường khi bạn muốn chia dữ liệu của mình thành các bảng nhỏ gọn gàng như bạn vẫn thường làm trước đây. Tôi đã phạm lỗi khi làm điều này khi mớ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 sẽ đánh mất 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 giống như lược đồ SQL Và đây là cách khiến tôi cảm thấy Tuy nhiên, tôi nghĩ tốt nhất là nên 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 với MongoDB đến từ đó. Vì vậy, hãy xem hai mẫu thiết kế này khác nhau như thế nào Thông thường, khi thiết kế một lược đồ quan hệ, các nhà phát triển sẽ lập 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ì?" . Mục đích của quá trình chuẩn hóa là chia nhỏ dữ liệu của bạn thành các bảng để bạn không bị trùng lặp dữ liệu. Hãy xem một ví dụ về cách bạn sẽ lập mô hình một số dữ liệu người dùng trong cơ sở dữ liệu quan hệ 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 ngoại trong cột 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ế lược đồ MongoDB, điều quan trọng duy nhất 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ững điều sau đây
Hãy xem cách chúng ta có thể lập 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 ta 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 mình Nhúng so với. tham khảoThiế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 cách sử dụ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
Được rồi, do đó, tùy chọn khác để thiết kế lược đồ của chúng ta là tham chiếu một tài liệu khác bằng cách sử dụng ID đối tượng duy nhất của tài liệu và kết nối chúng 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 chia nhỏ dữ liệu để thực hiện các truy vấn hiệu quả hơn và có thể mở rộng hơn, nhưng vẫn duy trì mối quan hệ giữa dữ liệu
Được rồi, bây giờ chúng ta đã khám phá hai cách mà chúng ta có thể phân tách dữ liệu khi thiết kế các lược đồ của mình 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 việc lập mô hình nếu bạn có nền tảng về SQL. Chúng tôi sẽ bắt đầu với các mối quan hệ đơn giản hơn và tiến tới một số mẫu và mối quan hệ thú vị cũng như 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 ta sẽ chỉ khám phá bề nổi của việc mô hình hóa các mối quan hệ trong MongoDB tại đâ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ê bên dưới, thì bạn có thể có một lược đồ hoàn toàn khác với lược đồ mà 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 đối với lược đồ của mình là hệ thống của bạn sẽ sử dụng dữ liệu như thế nào. Trong mỗi ví dụ, tôi sẽ phác thảo các yêu cầu cho từng ứng dụng và lý do 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 mình, hãy nhớ mở một cuộc trò chuyện trên Diễn đàn cộng đồng MongoDB và tất cả chúng ta có thể thảo luận về những gì sẽ hoạt động tốt nhất cho ứng dụng duy nhất của bạn 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 trực tiếp 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 đối một. Chúng tôi có thể lập mô hình tất cả dữ liệu một đối một dưới dạng các cặp khóa-giá trị trong cơ sở dữ liệu của mình
Được rồi, bây giờ giả sử rằng chúng ta đang xử lý một chuỗi dữ liệu nhỏ được liên kết với người dùng của chúng ta. Ví dụ: chúng tôi 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 chắc rằng một 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ẽ xác định đây là mối quan hệ một-vài Bạn có nhớ 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 không? . Tôi đã tạo ra một số quy tắc hữu ích để giúp bạn thiết kế lược đồ cho ứng dụng của mình Quy tắc 1. Ưu tiên nhúng trừ khi có lý do thuyết phục để không Nói chung, hành động mặc định của tôi là nhúng dữ liệu vào tài liệu. Mình lôi ra tham khảo chỉ khi nào cần truy cập riêng thôi, nó to quá ít khi cần đến hay lý do nào khác
Được rồi, giả sử bạn đang xây dựng 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 bộ phận tạo nên từng sản phẩm cho các dịch vụ sửa chữa. Bạn sẽ thiết kế lược đồ như thế nào để 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 hiệu quả? Giờ đây, với một lược đồ có khả năng lưu hàng nghìn phần phụ, chúng tôi có thể không cần phải có tất cả dữ liệu cho các phần trên mỗi yêu cầu đơn lẻ, nhưng điều quan trọng là mối quan hệ này được duy trì trong lược đồ của chúng tôi. Vì vậy, chúng tôi có thể có 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 mình và để giữ dữ liệu bộ 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 đến tài liệu có thông tin về bộ phận đó. Những 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 điều này sẽ trông như thế nào Quy tắc 2. Cần tự mình truy cập một đối tượng là lý do thuyết phục để không nhúng nó Quy tắc 3. Tránh tham gia/tra cứu nếu có thể, nhưng đừng sợ nếu họ có thể cung cấp một thiết kế lược đồ tốt hơn Điều gì sẽ xảy ra nếu chúng ta có một lược đồ trong đó có thể có hàng triệu tài liệu phụ hoặc nhiều hơn? . Và, tôi biết bạn đang nghĩ gì. _Có phải squillions là từ thật không?_ Và câu trả lời là có, nó là từ thật 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 lưu một lượng lớn dữ liệu, tùy thuộc vào mức độ chi tiết mà bạn đang ghi nhật ký và thời gian bạn lưu trữ nhật ký máy chủ trong bao lâu Với MongoDB, việc theo dõi dữ liệu trong một mảng không giới hạn là rất nguy hiểm, vì chúng tôi có khả năng đạt đến giới hạn 16 MB cho mỗi tài liệu đó. Bất kỳ máy chủ cụ thể nào cũng có thể tạo đủ thông báo để vượt quá kích thước tài liệu 16 MB, ngay cả khi chỉ 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 gặp phả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 tường trình trong tài liệu máy chủ, hãy để mỗi thông báo tường trình lưu trữ máy chủ mà thông báo của nó được liên kết với. Bằng cách lưu trữ dữ liệu trong nhật ký, chúng tôi không còn phải lo lắng về một mảng không giới hạn gây rối 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ể làm việc Quy tắc 4. Mảng không nên phát triển mà không có giới hạn. Nếu có hơn vài trăm tài liệu ở phía "nhiều", đừng nhúng chúng; . Mảng cardinality cao là một lý do thuyết phục để không nhúng Mẫu thiết kế lược đồ cuối cùng mà chúng ta sẽ trình bày trong bài đăng này là mối quan hệ nhiều-nhiều. Đây là một mẫu lược đồ rất phổ biến khác mà chúng ta luôn thấy trong các thiết kế lược đồ quan hệ và MongoDB. Đối với mẫu này, hãy tưởng tượng rằng chúng ta đang xây dựng một ứng dụng việc cần làm. Trong ứng dụng của chúng tôi, một 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ó Để duy trì các mối quan hệ này giữa người dùng và tác vụ, sẽ cần có các tham chiếu từ một người dùng đến nhiều tác vụ và tham chiếu từ một tác vụ đến nhiều người dùng. Hãy xem cách điều này có thể hoạt động đối với ứng dụng danh sách việc cần làm Từ ví dụ này, bạn có thể thấy rằng mỗi người dùng có một mảng phụ gồm các tác vụ được liên kết và mỗi tác vụ có một mảng phụ gồm các chủ sở hữu cho mỗi mục trong ứng dụng việc cần làm của chúng ta 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 chuẩn hóa dữ liệu của bạn như bạn có thể đã quen làm trong SQL. Bằng cách tận dụng lợi thế của việc nhúng dữ liệu trong tài liệu hoặc tham chiếu tài liệu bằng cách sử dụng toán tử tra cứu $, bạn có thể tạo 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 dành riêng cho ứng dụng của bạn. Trên thực tế, chúng tôi chỉ mới có thể khám phá sơ bộ về tất cả các cách mà bạn có thể lập mô hình dữ liệu của mình trong MongoDB. Nếu bạn muốn tìm hiểu thêm về thiết kế lược đồ MongoDB, hãy nhớ xem loạt bài tiếp theo 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 lập mô hình 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ách ứng dụng của bạn truy vấn và cập nhật dữ liệu đó Hãy nhớ rằng, mọi ứng dụng đều có nhu cầu và yêu cầu riêng, vì vậy thiết kế lược đồ phải 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 nghĩ 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 đó
Quy tắc chung cho thiết kế lược đồ MongoDB
Chúng tôi mới chỉ vạch ra bề nổi của các mẫu thiết kế trong MongoDB. Trên thực tế, chúng tôi thậm chí còn chưa bắt đầu khám phá các mẫu thậm chí không thể thực hiện từ xa trong mô hình quan hệ kế thừa. Nếu bạn muốn tìm hiểu thêm về các mẫu này, hãy xem các tài nguyên bên dưới |
