MongoDB
 sql >> Cơ Sở Dữ Liệu >  >> NoSQL >> MongoDB

Mối quan hệ MongoDB:nhúng hay tham chiếu?

Đây là một nghệ thuật hơn là một khoa học. Tài liệu Mongo về Lược đồ là một tài liệu tham khảo tốt, nhưng sau đây là một số điều cần xem xét:

  • Đặt càng nhiều càng tốt

    Niềm vui của cơ sở dữ liệu Tài liệu là nó loại bỏ rất nhiều Tham gia. Bản năng đầu tiên của bạn là đặt càng nhiều vào một tài liệu càng tốt. Bởi vì tài liệu MongoDB có cấu trúc và vì bạn có thể truy vấn hiệu quả trong cấu trúc đó (điều này có nghĩa là bạn có thể lấy một phần tài liệu mà bạn cần, vì vậy kích thước tài liệu không khiến bạn lo lắng nhiều) nên không cần phải chuẩn hóa dữ liệu ngay lập tức như bạn sẽ làm trong SQL. Đặc biệt, bất kỳ dữ liệu nào không hữu ích ngoài tài liệu gốc của nó phải là một phần của cùng một tài liệu.

  • Dữ liệu riêng biệt có thể được tham chiếu từ nhiều nơi vào bộ sưu tập của riêng nó.

    Đây không phải là vấn đề quá nhiều về "không gian lưu trữ" mà là vấn đề "tính nhất quán của dữ liệu". Nếu nhiều bản ghi sẽ tham chiếu đến cùng một dữ liệu thì sẽ hiệu quả hơn và ít bị lỗi hơn khi cập nhật một bản ghi và giữ các tham chiếu đến nó ở những nơi khác.

  • Cân nhắc kích thước tài liệu

    MongoDB áp đặt giới hạn kích thước 4MB (16MB với 1,8) trên một tài liệu. Trong một thế giới hàng GB dữ liệu, điều này nghe có vẻ nhỏ, nhưng nó cũng là 30 nghìn tweet hoặc 250 câu trả lời Stack Overflow điển hình hoặc 20 bức ảnh nhấp nháy. Mặt khác, đây là nhiều thông tin hơn những gì người ta có thể muốn trình bày cùng một lúc trên một trang web điển hình. Đầu tiên hãy xem xét điều gì sẽ làm cho các truy vấn của bạn dễ dàng hơn. Trong nhiều trường hợp, lo ngại về kích thước tài liệu sẽ bị tối ưu hóa quá sớm.

  • Cấu trúc dữ liệu phức tạp:

    MongoDB có thể lưu trữ các cấu trúc dữ liệu lồng nhau sâu tùy ý, nhưng không thể tìm kiếm chúng một cách hiệu quả. Nếu dữ liệu của bạn tạo thành một cây, rừng hoặc biểu đồ, bạn cần phải lưu trữ từng nút và các cạnh của nó trong một tài liệu riêng biệt. (Lưu ý rằng có những kho dữ liệu được thiết kế đặc biệt cho loại dữ liệu này mà người ta cũng nên xem xét)

    Nó cũng đã được chỉ ra rằng không thể trả về một tập hợp con các phần tử trong một tài liệu. Nếu bạn cần chọn và chọn một vài bit của mỗi tài liệu, thì việc tách chúng ra sẽ dễ dàng hơn.

  • Tính nhất quán của dữ liệu

    MongoDB đánh đổi giữa hiệu quả và tính nhất quán. Quy tắc là các thay đổi đối với một tài liệu là luôn luôn nguyên tử, trong khi các bản cập nhật cho nhiều tài liệu không bao giờ được giả định là nguyên tử. Cũng không có cách nào để "khóa" một bản ghi trên máy chủ (bạn có thể xây dựng bản ghi này thành logic của máy khách bằng cách sử dụng trường "khóa" chẳng hạn). Khi bạn thiết kế lược đồ của mình, hãy xem xét cách bạn sẽ giữ cho dữ liệu của mình nhất quán. Nói chung, bạn càng lưu giữ nhiều tài liệu thì càng tốt.

Đối với những gì bạn đang mô tả, tôi sẽ nhúng các nhận xét và cung cấp cho mỗi nhận xét một trường id với một ObjectID. ObjectID có một dấu thời gian được nhúng trong đó, do đó bạn có thể sử dụng nó thay vì được tạo nếu bạn muốn.



  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Cách thích hợp để nhập tệp json vào mongo

  2. Làm thế nào để đối phó với vấn đề múi giờ khi lưu trữ ngày trong utc bằng mongod?

  3. Chỉ nhận một trường được chỉ định trong MongoDB với C #

  4. Mẹo quản lý MongoDB từ xa

  5. Tạo chỉ mục văn bản đa ngôn ngữ trong MongoDB