Memahami batas ukuran Dokumen MongoDB BSON

Dari MongoDB Panduan Definitif:

Dokumen yang lebih besar dari 4MB (saat dikonversi ke BSON) tidak dapat disimpan ke database. Ini adalah batas yang agak arbitrer (dan dapat dinaikkan di masa depan); sebagian besar untuk mencegah desain skema buruk dan memastikan kinerja yang konsisten.

Saya tidak mengerti batas ini, apakah ini berarti bahwa Dokumen yang berisi posting Blog dengan banyak komentar yang kebetulan lebih besar dari 4MB tidak dapat disimpan sebagai dokumen tunggal?

Apakah ini juga menghitung dokumen bersarang?

Bagaimana jika saya ingin dokumen yang mengaudit perubahan ke nilai. (Pada akhirnya akan tumbuh, melebihi batas 4MB.)

Semoga seseorang menjelaskan ini dengan benar.

Saya baru saja mulai membaca tentang MongoDB (database nosql pertama yang saya pelajari).

Terima kasih.

Pertama, ini sebenarnya diangkat dalam versi berikutnya ke 8MBatau 16MB... tapi saya pikir untuk menempatkan ini ke dalam perspektif, Eliot dari 10gen (yang mengembangkan MongoDB) mengatakan yang terbaik:

EDIT: Ukuran telah resmi 'dinaikkan' menjadi16MB

Jadi, pada contoh blog Anda, 4MB sebenarnya sangat banyak .. Misalnya, teks lengkap tanpa kompres "War of the Worlds" hanya 364k (html): http://www.gutenberg.org/etext/36

Jika posting blog Anda selama itu dengan banyak komentar, saya tidak akan membacanya :)

Untuk trackback, jika Anda mendedikasikan 1MB untuknya, Anda dapat dengan mudah memiliki lebih dari 10rb (mungkin lebih dekat dengan 20rb)

Jadi kecuali untuk situasi yang benar-benar aneh, itu akan bekerja dengan baik. Dan dalam kasus pengecualian atau spam, saya benar-benar tidak berpikir Anda menginginkan objek 20MB. Saya pikir membatasi trackback sebagai 15k atau lebih masuk akal tidak peduli apa untuk kinerja. Atau setidaknya casing khusus jika pernah terjadi.

-Eliot

Saya pikir Anda akan sangat sulit ditekan untuk mencapai batas ... dan seiring waktu, jika Anda meningkatkan ... Anda harus semakin khawatir.

Poin utama dari batas ini adalah agar Anda tidak menggunakan semua RAM di server Anda (karena Anda perlu memuat semua MBdokumen ke dalam RAM ketika Anda menanyakannya.)

Jadi batasannya adalah beberapa% dari RAM normal yang dapat digunakan pada sistem umum ... yang akan terus tumbuh dari tahun ke tahun.

Catatan tentang Menyimpan File di MongoDB

Jika Anda perlu menyimpan dokumen (atau file) yang lebih besar daripada 16MBAnda dapat menggunakan API GridFS yang secara otomatis akan memecah data menjadi segmen-segmen dan mengalirkannya kembali ke Anda (sehingga menghindari masalah dengan batas ukuran / RAM.)

Alih-alih menyimpan file dalam satu dokumen, GridFS membagi file menjadi beberapa bagian, atau potongan, dan menyimpan setiap potongan sebagai dokumen terpisah.

GridFS menggunakan dua koleksi untuk menyimpan file. Satu koleksi menyimpan potongan file, dan lainnya menyimpan file metadata.

Anda dapat menggunakan metode ini untuk menyimpan gambar, file, video, dll dalam database sebanyak mungkin dalam database SQL. Saya telah menggunakan ini bahkan untuk menyimpan file video multi-gigabyte.

Banyak orang di komunitas lebih suka tanpa batas dengan peringatan tentang kinerja, lihat komentar ini untuk argumen yang beralasan: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin. system.issuetabpanels: comment-tabpanel # comment-22283

Saya kira, pengembang utama keras kepala tentang masalah ini karena mereka memutuskan itu adalah "fitur" penting sejak awal. Mereka tidak akan mengubahnya dalam waktu dekat karena perasaan mereka terluka bahwa ada yang mempertanyakannya. Contoh lain dari kepribadian dan politik yang mengurangi produk dalam komunitas open source tetapi ini bukan masalah yang melumpuhkan.

Untuk memposting jawaban klarifikasi di sini untuk mereka yang diarahkan di sini oleh Google.

Ukuran dokumen mencakup semua yang ada di dokumen termasuk sub dokumen, objek bersarang, dll.

Jadi dokumen dari:

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

Memiliki ukuran maksimum 16meg.

Dokumen-dokumen dan benda-benda bersarang dihitung berdasarkan ukuran dokumen.

Saya belum melihat masalah dengan batas yang tidak melibatkan file besar yang tersimpan dalam dokumen itu sendiri. Sudah ada berbagai database yang sangat efisien dalam menyimpan / mengambil file besar; mereka disebut sistem operasi. Basis data ada sebagai lapisan di atas sistem operasi. Jika Anda menggunakan solusi NoSQL untuk alasan kinerja, mengapa Anda ingin menambahkan overhead pemrosesan tambahan untuk akses data Anda dengan meletakkan lapisan DB antara aplikasi Anda dan data Anda?

JSON adalah format teks. Jadi, jika Anda mengakses data Anda melalui JSON, ini terutama benar jika Anda memiliki file biner karena harus dikodekan dalam uuencode, heksadesimal, atau Basis 64. Jalur konversi mungkin terlihat seperti

file biner <> JSON (disandikan) <> BSON (disandikan)

Akan lebih efisien untuk meletakkan path (URL) ke file data dalam dokumen Anda dan menyimpan data itu sendiri dalam biner.

Jika Anda benar-benar ingin menyimpan file-file ini dengan panjang yang tidak diketahui dalam DB Anda, maka Anda mungkin akan lebih baik meletakkannya di GridFS dan tidak berisiko membunuh konkurensi Anda ketika file besar diakses.

Kedalaman Bersarang untuk Dokumen BSON: MongoDB mendukung tidak lebih dari 100 level sarang untuk dokumen BSON.

Info lebih lanjut

Mungkin menyimpan posting blog -> hubungan komentar dalam database non-relasional sebenarnya bukan desain terbaik.

Anda mungkin harus menyimpan komentar dalam koleksi terpisah untuk posting blog.

[sunting]

Lihat komentar di bawah untuk diskusi lebih lanjut.

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

Jika Anda berharap bahwa posting blog dapat melebihi batas dokumen 16Mb, Anda harus mengekstraksi komentar ke dalam koleksi terpisah dan merujuk posting blog dari komentar dan melakukan penggabungan tingkat aplikasi.

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

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