Hiểu giới hạn kích thước tài liệu MongoDB BSON

Từ MongoDB Hướng dẫn dứt khoát:

Tài liệu lớn hơn 4MB (khi được chuyển đổi thành BSON) không thể được lưu vào cơ sở dữ liệu. Đây là một giới hạn tùy ý (và có thể được nêu ra trong tương lai); nó chủ yếu là để ngăn chặn thiết kế lược đồ xấu và đảm bảo hiệu suất phù hợp.

Tôi không hiểu giới hạn này, điều này có nghĩa là Tài liệu có chứa một bài đăng trên Blog có rất nhiều bình luận chỉ lớn hơn 4 MB không thể được lưu trữ dưới dạng một tài liệu?

Điều này cũng tính các tài liệu lồng nhau quá?

Điều gì xảy ra nếu tôi muốn một tài liệu kiểm tra các thay đổi thành giá trị. (Cuối cùng nó sẽ có thể phát triển, vượt quá giới hạn 4 MB.)

Hy vọng ai đó giải thích điều này một cách chính xác.

Tôi mới bắt đầu đọc về MongoDB (cơ sở dữ liệu nosql đầu tiên tôi đang tìm hiểu).

Cảm ơn bạn.

Trước hết, điều này thực sự đang được nâng lên trong phiên bản tiếp theo 8MBhoặc 16MB... nhưng tôi nghĩ để đưa điều này vào viễn cảnh, Eliot từ 10gen (người đã phát triển MongoDB) đưa nó tốt nhất:

EDIT: Kích thước đã chính thức được 'nâng' lên16MB

Vì vậy, trên ví dụ blog của bạn, 4MB thực sự là rất nhiều .. Ví dụ: toàn bộ văn bản giải nén của "Chiến tranh thế giới" chỉ có 364k (html): http://www.gutenberg.org/etext/36

Nếu bài đăng trên blog của bạn dài như vậy với nhiều bình luận, tôi sẽ không đọc nó :)

Đối với trackback, nếu bạn dành riêng 1MB cho chúng, bạn có thể dễ dàng có hơn 10k (có thể gần hơn 20k)

Vì vậy, ngoại trừ những tình huống thực sự kỳ lạ, nó sẽ hoạt động rất tốt. Và trong trường hợp ngoại lệ hoặc spam, tôi thực sự không nghĩ rằng bạn muốn có một đối tượng 20mb. Tôi nghĩ giới hạn theo dõi là 15k hoặc hơn rất nhiều ý nghĩa cho dù hiệu suất. Hoặc ít nhất là vỏ đặc biệt nếu nó từng xảy ra.

-Eliot

Tôi nghĩ rằng bạn sẽ khá khó khăn để đạt đến giới hạn ... và theo thời gian, nếu bạn nâng cấp ... bạn sẽ phải lo lắng ngày càng ít đi.

Điểm chính của giới hạn là vì vậy bạn không sử dụng hết RAM trên máy chủ của mình (vì bạn cần tải tất cả MBs của tài liệu vào RAM khi bạn truy vấn nó.)

Vì vậy, giới hạn là một số% RAM có thể sử dụng bình thường trên một hệ thống chung ... sẽ tiếp tục tăng lên hàng năm.

Lưu ý về việc lưu trữ tệp trong MongoDB

Nếu bạn cần lưu trữ tài liệu (hoặc tệp) lớn hơn 16MBbạn có thể sử dụng API GridFS , nó sẽ tự động chia dữ liệu thành các phân đoạn và truyền chúng lại cho bạn (do đó tránh được vấn đề về giới hạn kích thước / RAM.)

Thay vì lưu trữ một tệp trong một tài liệu, GridFS chia tệp thành các phần hoặc khối và lưu trữ từng đoạn dưới dạng một tài liệu riêng biệt.

GridFS sử dụng hai bộ sưu tập để lưu trữ các tập tin. Một bộ sưu tập lưu trữ các khối tệp và bộ lưu trữ siêu dữ liệu khác.

Bạn có thể sử dụng phương pháp này để lưu trữ hình ảnh, tệp, video, v.v. trong cơ sở dữ liệu nhiều như bạn có thể trong cơ sở dữ liệu SQL. Tôi đã sử dụng điều này để thậm chí lưu trữ các tập tin video nhiều gigabyte.

Nhiều người trong cộng đồng không muốn có giới hạn với các cảnh báo về hiệu suất, hãy xem nhận xét này để biết lý lẽ hợp lý: https://jira.mongodb.org/browse/SERVER-431?f FocusedVerId = 22283 & page = com.atlassian.jira.plugin . system.issuetabpanels: bình luận-tabpanel # bình luận-22283

Tôi nghĩ, các nhà phát triển chính rất bướng bỉnh về vấn đề này bởi vì họ đã quyết định rằng đây là một "tính năng" quan trọng từ rất sớm. Họ sẽ không thay đổi nó bất cứ lúc nào sớm vì cảm xúc của họ bị tổn thương mà bất cứ ai cũng nghi ngờ điều đó. Một ví dụ khác về tính cách và chính trị làm mất tập trung từ một sản phẩm trong các cộng đồng nguồn mở nhưng đây không thực sự là một vấn đề tê liệt.

Để đăng câu trả lời làm rõ ở đây cho những người được Google hướng dẫn ở đây.

Kích thước tài liệu bao gồm mọi thứ trong tài liệu bao gồm các bản đồ con, các đối tượng lồng nhau, v.v.

Vì vậy, một tài liệu về:

{
    _id:{},
    na: [1,2,3],
    naa: [
        {w:1,v:2,b:[1,2,3]},
        {w:5,b:2,h:[{d:5,g:7},{}]}
    ]
}

Có kích thước tối đa 16meg.

Sbudocument và các đối tượng lồng nhau đều được tính vào kích thước của tài liệu.

Tôi chưa thấy vấn đề với giới hạn không liên quan đến các tệp lớn được lưu trữ trong chính tài liệu. Hiện đã có một loạt các cơ sở dữ liệu rất hiệu quả trong việc lưu trữ / truy xuất các tệp lớn; chúng được gọi là hệ điều hành. Cơ sở dữ liệu tồn tại dưới dạng một lớp trên hệ điều hành. Nếu bạn đang sử dụng giải pháp NoQuery vì lý do hiệu năng, tại sao bạn muốn thêm chi phí xử lý bổ sung vào quyền truy cập dữ liệu của mình bằng cách đặt lớp DB giữa ứng dụng và dữ liệu của bạn?

JSON là một định dạng văn bản. Vì vậy, nếu bạn đang truy cập dữ liệu của mình thông qua JSON, điều này đặc biệt đúng nếu bạn có tệp nhị phân vì chúng phải được mã hóa theo uuencode, hexadecimal hoặc Base 64. Đường dẫn chuyển đổi có thể trông giống như

tệp nhị phân <> JSON (được mã hóa) <> BSON (được mã hóa)

Sẽ hiệu quả hơn nếu đặt đường dẫn (URL) vào tệp dữ liệu trong tài liệu của bạn và giữ dữ liệu ở dạng nhị phân.

Nếu bạn thực sự muốn giữ các tệp này có độ dài không xác định trong DB của mình, thì có lẽ tốt hơn hết bạn nên đặt chúng trong GridFS và không mạo hiểm giết chết đồng thời của bạn khi các tệp lớn được truy cập.

Độ sâu lồng nhau cho tài liệu BSON: MongoDB hỗ trợ không quá 100 cấp độ lồng cho tài liệu BSON.

Thêm thông tin chi tiết

Có lẽ lưu trữ một bài đăng blog -> quan hệ bình luận trong cơ sở dữ liệu không liên quan không thực sự là thiết kế tốt nhất.

Bạn có lẽ nên lưu trữ ý kiến ​​trong một bộ sưu tập riêng biệt cho các bài đăng blog.

[biên tập]

Xem ý kiến ​​dưới đây để thảo luận thêm.

Theo https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1

Nếu bạn cho rằng một bài đăng trên blog có thể vượt quá giới hạn tài liệu 16Mb, bạn nên trích xuất các nhận xét thành một bộ sưu tập riêng và tham khảo bài đăng trên blog từ nhận xét và tham gia ở cấp độ ứng dụng.

// posts
[
  {
    _id: ObjectID('AAAA'),
    text: 'a post',
    ...
  }
]

// comments
[
  {
    text: 'a comment'
    post: ObjectID('AAAA')
  },
  {
    text: 'another comment'
    post: ObjectID('AAAA')
  }
]