MongoDB thực sự hoạt động như thế nào?

Question

thể trùng lặp:
How to represent the data for threaded comments(along with comment voting) in mongodb?

Tôi đến từ mysql trên thế giới và đã quyết định học cách sử dụng MongoDB. Dự án sắp tới của tôi sẽ tương tự như Reddit.com với bình luận và bỏ phiếu đa cấp. Bạn có thể vui lòng hướng dẫn tôi đến một tài nguyên tốt để hiểu cách xây dựng ứng dụng bằng cách sử dụng mongodb không? Tôi hiểu cách lưu trữ tài liệu cơ bản hoạt động, nhưng không thể che giấu đầu tôi về cách lưu trữ các nhận xét và thông tin người dùng trong một tài liệu và cập nhật nếu ai đó cập nhật thông tin người dùng của họ. Vì vậy, về cơ bản tôi đang tìm kiếm một hướng dẫn di chuyển từ mysql để mongodb.

Mọi lời khuyên/hướng dẫn được đánh giá cao.

Answer 1

Lý do tại sao bạn gặp khó khăn khi gói đầu xung quanh vì MongoDB không phải là relational database, là document-oriented database. Đối với một cái gì đó đơn giản như một cây bình luận với một cấu trúc rất thiết lập và một mối quan hệ một-nhiều bạn có lẽ sẽ là tốt nhất off gắn bó với MySQL. Hồ sơ người dùng có thể là một điều thú vị để sử dụng MongoDB cho, nhưng một lần nữa, nếu nó rất có cấu trúc, bạn có thể tốt hơn với MySQL.

Bạn có thể muốn xác định các khía cạnh nào của dự án phù hợp nhất với cơ sở dữ liệu định hướng tài liệu (IE: dữ liệu phi cấu trúc) và các khía cạnh nào tốt nhất để sử dụng cơ sở dữ liệu quan hệ truyền thống hơn.

Một câu hỏi trước mà tôi hỏi có một cái nhìn tổng quan tốt của cả hai: Are document-oriented databases meant to replace relational databases?

Tôi cũng đã được sử dụng cả trong các dự án với rất nhiều thành công, mặc dù nó có một số lượng đáng kể các thiết lập ban đầu như hầu hết các khuôn khổ làm không cho phép triển khai cả hai quá dễ dàng.

Answer 2

Một số quy tắc của ngón tay cái mà tôi đã tìm thấy hữu ích là điều này:

• Nếu chỉ có một bản sao logic của một mẩu thông tin, nó phải là trong một tài liệu (ví dụ, nếu bạn có ý kiến trên một bài đăng, phương pháp đơn giản nhất là nhúng chúng vào bài đăng)

• Nếu bạn không chuẩn hóa dữ liệu trong SQL vào một số bảng khác để tránh tham gia và không có điều gì, hành vi tương tự được áp dụng trong lưu trữ tài liệu: không chuẩn hóa từ một " chính "vị trí thành bản sao ở các vị trí khác. Các bản sao nên được coi là bản sao và không phải là thông tin gốc, vì vậy chúng có thể được ghi đè bằng các hành động không chuẩn hóa trong tương lai.

• Nếu bạn phải truy nhập một tập hợp dữ liệu chuẩn, như tài khoản người dùng, từ nhiều vị trí, lưu trữ tham chiếu dưới dạng ObjectId s trong mongodb, sau đó thực hiện truy vấn thứ hai cho tài liệu liên quan. Bạn phải lưu ý trong ứng dụng của mình rằng truy vấn thứ hai không tham gia và sẽ không khóa cả hai tài liệu để đảm bảo tính nhất quán, do đó có thể có sự không thống nhất trong kết quả.

Về cơ bản, bạn nên nghĩ cơ sở dữ liệu là nhất quán ở cấp tài liệu. Bất kỳ truy vấn nào của các tài liệu liên quan có thể không phù hợp, vì vậy nếu bạn cần sự nhất quán, bạn có thể không chuẩn hóa dữ liệu đó thành một tài liệu.

Nếu bạn cần tài khoản người dùng được chính xác phù hợp với ý kiến ​​của bạn, bạn sẽ phải sao chép các thông tin có liên quan bên cạnh ý kiến ​​của bạn tại cùng một thời điểm mà bạn viết bình luận vào tài liệu. Điều này có nghĩa là bạn phải suy nghĩ về sự nhất quán ở cấp ứng dụng, mọi lúc. Nếu không, như tôi nghi ngờ là trường hợp, chỉ cần đưa ra một truy vấn khác cho người dùng.

Nếu bạn lo ngại về hiệu suất truy vấn dữ liệu trên tất cả người dùng tham gia vào trang của bạn, tôi khuyên bạn nên sao chép một số dữ liệu từ tài khoản người dùng bên cạnh nhận xét, nhưng chỉ đọc từ bản sao này - bạn nên ghi vào tài khoản người dùng ban đầu của bạn.

Đó là tất cả những gì nói đến cái tâm cho bây giờ, nhưng tôi có thể chỉnh sửa như điều xảy ra đối với tôi :)