Mẫu tính toán MongoDB
|
đăng nội dung. Sau khi hoàn thành khóa học mô hình hóa dữ liệu của Đại học MongoDB, tôi quyết định viết ra một số nguyên tắc quan trọng của mô hình hóa dữ liệu trong MongoDB mà tôi đã học được Show
Nếu bạn đã hỏi tôi một tuần trước lợi thế của việc sử dụng cơ sở dữ liệu MongoDB là gì, tôi sẽ nói với bạn. bởi vì nó linh hoạt và không có sơ đồ. Nhưng đây có thực sự là câu trả lời? Gần đây tôi bắt đầu làm việc trên một ứng dụng mới và quyết định sử dụng MongoDB làm cơ sở dữ liệu. Tôi đã thiết kế mô hình dữ liệu của mình giống hệt với mô hình tôi sẽ thiết kế nếu làm việc với cơ sở dữ liệu quan hệ, chẳng hạn như PostgreSQL. Tuy nhiên, sau khi xem một số video về mô hình hóa dữ liệu và tham gia một khóa học tại trường đại học MongoDB, tôi nhận ra rằng mình đã bỏ lỡ rất nhiều thứ mà MongoDB thực sự phải cung cấp. Để thiết kế một mô hình dữ liệu tốt trong MongoDB, tôi phải thực hiện chuyển ngữ cảnh từ thế giới quan hệ sang thế giới của NoSQL Tính linh hoạt thực sự có nghĩa là gìKhông có sơ đồ và tính linh hoạt của MongoDB mang lại hai lợi thế
Với MongoDB, mô hình dữ liệu của bạn có thể được thiết kế theo bất kỳ cách nào bạn thấy phù hợp với ứng dụng của mình Trong thế giới quan hệ, mô hình hóa dữ liệu được thực hiện khi bắt đầu phát triển và hiếm khi thay đổi trong suốt quá trình phát triển. Ngoài ra, khi thiết kế mô hình dữ liệu cho cơ sở dữ liệu quan hệ, chúng ta chủ yếu chỉ nhìn vào dữ liệu chúng ta có - chúng ta đưa ra danh sách các thực thể (bảng), mối quan hệ giữa chúng và sau đó chuẩn hóa mô hình để tránh trùng lặp Trong MongoDB, mô hình hóa dữ liệu được thực hiện có tính đến ứng dụng. Chúng tôi trải qua một loạt các giai đoạn để xác định mô hình dữ liệu của mình, nhưng lợi ích là chúng tôi có thể thực hiện điều này nhiều lần khi ứng dụng của chúng tôi phát triển và chúng tôi hiểu rõ hơn về vị trí tắc nghẽn và hoạt động nào là quan trọng nhất. Chúng tôi cũng không bị giới hạn bởi bất kỳ loại bình thường hóa nào. Có, chúng tôi thậm chí có thể sao chép dữ liệu, nếu điều này cho phép chúng tôi nhanh hơn. Luôn có sự đánh đổi giữa tính đơn giản và hiệu suất - tính đơn giản có thể cho phép chúng tôi nhanh chóng khởi chạy dự án của mình, trong khi hiệu suất sẽ khiến mọi thứ trở nên phức tạp hơn vì mục đích tối ưu hóa. Điểm hay của MongoDB là chúng ta luôn có thể bắt đầu đơn giản và sau đó di chuyển mô hình dữ liệu của mình sang một phiên bản hiệu suất cao hơn một cách dễ dàng Giới hạn phần cứngTrong dữ liệu MongoDB được lưu trữ dưới dạng BSON, được giới hạn ở 16 MB cho mỗi tài liệu. Ngoài ra, WiredTiger, công cụ lưu trữ đằng sau MongoDB, cần tải toàn bộ tài liệu vào RAM khi thực hiện các thao tác đọc. Điều này có nghĩa là ngay cả khi chúng tôi chỉ cần tìm nạp một thuộc tính của thực thể, toàn bộ tài liệu với tất cả dữ liệu được nhúng sẽ được tải. Nếu một thực thể lớn thường xuyên được truy vấn, điều này sẽ khiến MongoDB ghi dữ liệu để hoán đổi, nhường chỗ cho các thực thể mới. Các thực thể đại diện cho các đối tượng được truy cập thường xuyên được gọi là khối lượng công việc và chúng tôi muốn giảm thiểu quy mô của khối lượng công việc nhiều nhất có thể Phương pháp mô hình hóa dữ liệuChúng tôi lặp lại các bước này nhiều lần trong suốt quá trình phát triển ứng dụng. Trong suốt các bước, chúng tôi đưa ra một số giả định, có thể sai. Nếu điều này xảy ra, có thể đã đến lúc thực hiện lại các bước này, thiết kế mô hình dữ liệu mới và áp dụng di chuyển 1. Mô tả khối lượng công việcChúng tôi xem xét bất kỳ tài nguyên nào chúng tôi có để có ý tưởng về cách ứng dụng sẽ trông như thế nào, chẳng hạn như xem xét nguyên mẫu, thiết kế, nói chuyện với chuyên gia miền và xem nhật ký. Do đó, chúng tôi có được ý tưởng về khối lượng công việc mà ứng dụng sẽ có. Chúng tôi tự hỏi mình những câu hỏi, chẳng hạn như
2. Các mối quan hệSau khi đưa ra danh sách các thực thể, chúng tôi xác định mối quan hệ giữa chúng. Ví dụ: một người dùng có nhiều bài đăng, mỗi bài đăng có nhiều bình luận và mỗi bình luận có một tác giả. Có vẻ đủ hợp lý và trong thế giới quan hệ, chúng ta sẽ biết chính xác cách mô hình hóa điều này. Nhưng trong MongoDB, chúng ta phải tự hỏi mình. nhúng hoặc tham chiếu? Tham chiếu tương tự như khóa ngoại trong thế giới quan hệ. Ví dụ: chúng ta có thể tạo một thực thể bài đăng và đặt author_id vào đó, tham chiếu đến thực thể người dùng Nhúng cho phép chúng tôi tránh tham gia bằng cách đặt tài liệu phụ vào thực thể. Ví dụ: chúng ta có thể nhúng mảng bài đăng vào người dùng và gọi nó là bài đăng. Tuy nhiên, chúng ta phải lưu ý đến
1. mối quan hệ NChúng ta có thể giải quyết 1. mối quan hệ N bởi a) Nhúng vào phía "một" của mối quan hệ (mảng đối tượng, ví dụ:. người dùng có danh sách các bài đăng) - chúng tôi thực hiện việc này nếu số lượng đối tượng trong mảng sẽ chỉ là một số ít và nếu việc trình bày dữ liệu này cùng nhau là hợp lý (tức là. nó thường được trình bày cùng nhau ở mặt trước) b) Nhúng vào phía "nhiều" (chúng tôi nhúng tác giả vào phía bài đăng) - điều này gây ra sự trùng lặp nhưng có thể tốt hơn nếu phía "nhiều" được truy vấn thường xuyên hơn phía "một" c) Tham chiếu về phía "một" (mảng tham chiếu, ví dụ:. người dùng có danh sách các tham chiếu đến bài đăng) - điều này cho phép các tài liệu nhỏ hơn nhiều và hữu ích nếu các thực thể không cần được trình bày cùng nhau. Tuy nhiên, nó yêu cầu thực hiện xóa theo tầng theo cách thủ công d) Tham khảo ở phía "nhiều" (chúng tôi tham khảo id tác giả ở phía bên của bài đăng) - hữu ích nếu chúng tôi có nhiều tài liệu và nó cho phép chúng tôi dễ dàng xóa theo tầng N. mối quan hệ MChúng ta có thể giải quyết N. mối quan hệ M bởi a) Nhúng vào phía "chính" - bất kỳ phía nào của mối quan hệ được truy vấn nhiều hơn ("chính"), sẽ nhận tài liệu được nhúng (ví dụ:. giỏ hàng và các mặt hàng). Các thực thể trùng lặp ở phía "không chính" vẫn được giữ, điều này có thể cần thiết (ví dụ:. diễn viên tồn tại trước khi họ hành động trong bất kỳ động thái nào) b) Tham chiếu ở phía "chính" c) Tham chiếu ở phía "phụ" 1. 1 mối quan hệChúng ta chỉ cần nhúng bất kỳ 1. 1, tuy nhiên, để giữ cho khối lượng công việc nhỏ, chúng tôi cũng có thể giới thiệu một thực thể riêng biệt để lưu trữ ít dữ liệu được truy vấn hơn trong đó và sử dụng tham chiếu đến thực thể ban đầu 1. mối quan hệ ZillionsTrong thế giới dữ liệu lớn 1. Hàng tỷ mối quan hệ chiếm ưu thế, mỗi cảm biến gửi nhiều dữ liệu cùng một lúc. Giải pháp duy nhất trong trường hợp này là tham khảo ở phía "nhiều" 3. Các mẫu mô hình hóa dữ liệuCác mẫu mô hình hóa dữ liệu cho phép chúng tôi tối ưu hóa mô hình dữ liệu của mình. Đây là lúc "sự tự do" của NoSQL phát huy tác dụng - chúng ta có thể làm bất cứ điều gì chúng ta muốn, để có khả năng cải thiện hiệu suất. Mô hình hóa dữ liệu là tất cả về các giả định và sự đánh đổi. Chúng tôi giả định rằng một số truy vấn nhất định sẽ được thực thi thường xuyên hơn nhiều so với các truy vấn khác. Chúng ta nên cố gắng tối ưu hóa các truy vấn này và thậm chí có khả năng làm chậm các truy vấn hiếm gặp khác. Đó là sự đánh đổi. Hãy nhớ rằng, chúng tôi muốn
Một số lo ngại về việc sử dụng các mẫu
Hãy xem xét một số mẫu mô hình hóa dữ liệu (tất cả chúng đều được giải thích rất chi tiết tại đây) mẫu thuộc tínhChúng tôi có các tài liệu có chung đặc điểm, nhưng một số trường chỉ xuất hiện trong một lượng nhỏ tài liệu (ví dụ:. sản phẩm trên trang thương mại điện tử). Chúng tôi muốn có thể sắp xếp hoặc truy vấn trên những trường hiếm đó. Chúng tôi làm điều này bằng cách tận dụng các chỉ số - chúng tôi tạo một mảng các đối tượng có 2 thuộc tính. khóa và giá trị Mẫu tham chiếu mở rộngChúng tôi muốn tránh các tham gia lặp đi lặp lại. Ví dụ: nếu chúng tôi có một trang mạng xã hội và trung tâm của sự chú ý (khối lượng công việc) là các bài đăng, chúng tôi không muốn tham gia các bài đăng với người dùng mỗi khi chúng tôi hiển thị bài đăng với tác giả của nó. Thay vào đó, chúng tôi có thể nhúng một số dữ liệu tác giả vào chính bài đăng, do đó sao chép dữ liệu để tránh tham gia. Nhưng điều này chỉ có thể hoạt động, nếu chúng ta nhúng tên và ảnh hồ sơ của người dùng chẳng hạn - tần suất người dùng thay đổi tên và ảnh hồ sơ của họ so với số lần họ duyệt các bài đăng? Do đó, khi sử dụng mẫu tham chiếu mở rộng, chúng ta phải tự hỏi mình
Chúng tôi có thể cập nhật bản sao trong khi chúng tôi thực hiện truy vấn cập nhật hoặc sau đó trong một đợt mẫu tập hợp conChúng tôi muốn giảm kích thước tập làm việc. Một điều chúng ta có thể làm là lưu trữ các thuộc tính hiếm khi được truy cập trong một thực thể riêng biệt và liên kết với nó từ thực thể chính. Trong trường hợp mạng xã hội, chúng tôi cũng có thể chỉ lưu trữ các bài đăng gần đây nhất của người dùng trong thực thể người dùng và lưu trữ phần còn lại trong một thực thể khác. Điều này một lần nữa phụ thuộc rất nhiều vào cách dữ liệu được hiển thị trên giao diện người dùng mẫu tính toánNếu chúng tôi truy vấn thường xuyên hơn chúng tôi viết, chúng tôi có thể muốn tính toán trước một số thuộc tính để tránh tính toán lặp đi lặp lại cùng một kết quả. Giả sử chúng ta có một mạng xã hội nơi người dùng có thể cho điểm các bài đăng từ 1 đến 10 và tổng số điểm của bài đăng là tổng của tất cả các điểm. Điểm sẽ được hiển thị mỗi khi chúng tôi xem một bài đăng. Chúng tôi có thể tính toán trước điểm số và lưu trữ nó trong bài đăng thay vì tính toán nhanh chóng mỗi khi chúng tôi tìm nạp bài đăng. Điều này hoạt động nếu chúng tôi tìm nạp các bài đăng thường xuyên hơn chúng tôi chấm điểm (điều mà chúng tôi thường làm). Khi cập nhật điểm, chúng tôi có thể thực hiện mỗi khi điểm xảy ra hoặc chúng tôi có thể thực hiện công việc hàng loạt nếu độ ổn định có thể chấp nhận được mô hình xôNếu tài liệu trở nên quá lớn do có nhiều dữ liệu dạng mảng (ví dụ:. đọc cảm biến), chúng tôi có thể chia dữ liệu theo một giá trị nhất định, ví dụ:. một ngày. Do đó, chúng tôi tạo ra các nhóm dữ liệu. Trong ví dụ đọc cảm biến, chúng tôi có thể tạo một tài liệu trên 100 lần đọc hoặc một tài liệu mỗi ngày, trong đó chúng tôi lưu trữ tất cả dữ liệu. Chiến lược xô thông minh có thể cho phép chúng tôi phân trang dữ liệu tốt hơn hoặc xóa dữ liệu cũ dễ dàng Mẫu phiên bản lược đồHãy nhớ rằng tôi đã nói rằng việc di chuyển dễ dàng hơn với MongoDB. Mẫu phiên bản lược đồ là lý do tại sao. Trong mẫu này, chúng tôi thêm thuộc tính schema_version vào tài liệu, thuộc tính này phản ánh lược đồ mà tài liệu cũng tuân thủ. Giả sử rằng chúng ta có lược đồ cũ (v1) và lược đồ mới, được tối ưu hóa (v2). Chúng tôi gán schema_version cho v1 cho tất cả các tài liệu cũ. Sau đó, chúng tôi triển khai xử lý cả v1 và v2 trên giao diện người dùng của mình (có thể chúng tôi chèn một số tài liệu v2 mẫu). Cuối cùng, chúng tôi bắt đầu thêm tài liệu mới dưới dạng v2 vào cơ sở dữ liệu của mình. Sau này, chúng tôi cũng có thể di chuyển tất cả tài liệu v1 sang v2 và xóa mã hỗ trợ v1 Điều kích hoạt mô hình này là tính không lược đồ và tính linh hoạt của MongoDB mô hình đa hìnhVì MongoDB không có lược đồ và linh hoạt nên không phải tất cả các tài liệu trong một bộ sưu tập đều cần chia sẻ cùng một lược đồ. Nếu chúng ta có các tài liệu giống nhau về bản chất, nhưng có một số thuộc tính khác nhau, chúng ta có thể lưu trữ chúng trong cùng một bộ sưu tập và thêm thuộc tính loại để phân biệt giữa chúng trong ứng dụng của chúng ta. Điều này cho phép chúng tôi triển khai giải pháp một chế độ xem - dữ liệu khác nhau được sử dụng cho cùng một mục đích hoặc được hiển thị trên cùng một màn hình mẫu xấp xỉChúng tôi ước tính các giá trị nhất định thay vì tính toán chúng mỗi lần - ví dụ:. lượt xem trang mẫu ngoại lệMột số tài liệu trong bộ dữ liệu của chúng tôi có thể nổi bật so với đám đông (ví dụ:. những người có nhiều người theo dõi trên mạng xã hội) - chúng tôi không muốn điều chỉnh toàn bộ hệ thống và có khả năng làm chậm hệ thống chỉ vì lợi ích của một vài ngoại lệ. Do đó, chúng tôi có thể chỉ cần điều chỉnh các ngoại lệ. Ví dụ: chúng tôi có thể thêm thuộc tính has_extra_followers cho người dùng phương tiện truyền thông xã hội của mình và sau đó áp dụng mẫu nhóm Đây là trường hợp sử dụng - chúng tôi có một trang mạng xã hội nơi chúng tôi có người dùng, những người có thể tạo hai loại bài đăng. một bài đăng thông thường có văn bản và bài đăng đặc biệt, chứa vị trí và các mô tả bổ sung. Người dùng có thể nhận xét về các bài đăng này Làm cách nào để chúng tôi tối ưu hóa danh sách các bài đăng của người dùng?
Trong thế giới quan hệ, tôi có thể lưu trữ cái này dưới dạng 3 thực thể riêng biệt hoặc thậm chí có thể là 4 trong số chúng (nếu chúng tôi tách các bài đăng và bài đăng đặc biệt). Điều này sẽ khiến mỗi bài đăng này gây ra 2 lần tham gia
Dưới đây là các tối ưu hóa mà chúng ta có thể áp dụng bằng MongoDB
lưu ý thú vị. mẫu xô có thể được áp dụng dễ dàng bằng cách sử dụng tham chiếu hoạt động upsert MongoDB so với PostgreSQLMongoDB thường nhanh hơn khi ghi, do thực tế là không cần kiểm tra ràng buộc dữ liệu. Nếu mô hình dữ liệu của chúng tôi được thiết kế tốt, việc đọc có thể nhanh hơn do thiếu liên kết. Sắp xếp nhanh hơn trong PostgreSQL vì đang tham gia và chọn mà không cần khóa. Tập hợp nhanh hơn với MongoDB và việc đếm cũng có thể nhanh hơn nếu chúng ta sử dụng mẫu được tính toán Lựa chọn cơ sở dữ liệu phù hợpKhông có công thức cố định, nhưng chúng ta có thể xem xét một số tùy chọn
Phần kết luậnHy vọng điều này mang lại cho bạn ý tưởng về cách MongoDB có thể tăng tốc ứng dụng của bạn. Mô hình hóa dữ liệu là một quy trình rất phức tạp đòi hỏi nhà phát triển phải biết nhiều về ứng dụng (đặc biệt là giao diện người dùng), đưa ra các giả định, tối ưu hóa lược đồ dần dần và không sợ phải đánh đổi (ví dụ:. sao chép dữ liệu để thực hiện truy vấn nhanh hơn) Các mẫu trong MongoDB là gì?Mẫu thuộc tính hữu ích cho các sự cố dựa trên việc có các tài liệu lớn với nhiều trường giống nhau nhưng có một tập hợp con các trường có chung đặc điểm và chúng tôi muốn sắp xếp hoặc truy vấn trên tập hợp con các trường đó. Khi các trường chúng ta cần sắp xếp chỉ được tìm thấy trong một tập hợp con nhỏ các tài liệu
Xô trong MongoDB là gì?Định nghĩa. $bucket. Phân loại tài liệu đến thành các nhóm, được gọi là nhóm, dựa trên một biểu thức và ranh giới nhóm đã chỉ định, đồng thời xuất một tài liệu cho mỗi nhóm . Mỗi tài liệu đầu ra chứa một trường _id có giá trị chỉ định giới hạn dưới bao gồm của nhóm.
mẫu tập hợp con là gì?Mẫu này giải quyết các vấn đề liên quan đến bộ làm việc vượt quá RAM, dẫn đến thông tin bị xóa khỏi bộ nhớ . Điều này thường xảy ra do các tài liệu lớn có nhiều dữ liệu không được ứng dụng thực sự sử dụng.
MongoDB dùng để làm gì?MongoDB là cơ sở dữ liệu tài liệu được sử dụng để xây dựng các ứng dụng internet có khả năng mở rộng và khả dụng cao . Với cách tiếp cận lược đồ linh hoạt, nó phổ biến với các nhóm phát triển sử dụng các phương pháp nhanh. |
