MongoDB BSON Belge boyutu sınırını anlama

MongoDB'den Kesin Kılavuz:

4 MB'tan büyük belgeler (BSON'a dönüştürüldüğünde) veritabanına kaydedilemez. Bu biraz keyfi bir sınırdır (ve gelecekte de arttırılabilir); çoğunlukla kötü şema tasarımını önlemek ve tutarlı performans sağlamaktır.

Bu sınırı anlamıyorum, bu, 4 MB'den daha büyük olan çok sayıda yorum içeren bir Blog yayını içeren bir Dokümanın tek bir doküman olarak saklanamayacağı anlamına mı geliyor?

Ayrıca bu iç içe geçmiş belgeleri de sayar mı?

Bir değerdeki değişiklikleri denetleyen bir belge istesem ne olur? (Sonunda 4 MB sınırını aşarak büyüyebilir.)

Umarım birisi bunu doğru bir şekilde açıklar.

Sadece MongoDB (ilk öğrendiğim nosql veritabanı) hakkında okumaya başladım.

Teşekkür ederim.

Öncelikle, bu aslında bir sonraki versiyonda yükseltiliyor 8MBveya 16MB... ama bunu perspektif haline getirmeyi düşünüyorum, 10gen'den (MongoDB'yi geliştiren) Eliot bunu en iyi şekilde ortaya koyuyor:

EDIT: Boyut resmi olarak 'yükseltildi'16MB

Yani, blog örneğinizde, 4MB aslında çok fazla .. Örneğin, "World of Wars" ın tam sıkıştırılmamış metni sadece 364k (html): http://www.gutenberg.org/etext/36

Blog yazınız bu kadar çok yorumla o kadar uzunsa, bir tanesi için ben okumam :)

Geri izleme için, onlara 1 MB ayırdıysanız, kolayca 10k'den fazla olabilirsiniz (muhtemelen 20k'ye daha yakın)

Bu yüzden gerçekten tuhaf durumlar dışında, harika çalışır. İstisna durumunda veya spam durumunda, yine de 20mb'lik bir nesne isteyeceğinizi düşünmüyorum. Ben geri izleme 15k ya da öylesine kapak performans için ne olursa olsun çok mantıklı düşünüyorum. Ya da en azından özel bir kasa olursa.

-Eliot

Sanırım sınıra ulaşmak için oldukça zorlanacaksınız ... ve zamanla, yükseltme yaparsanız ... daha az endişelenmeniz gerekecek.

Limitin ana noktası, sunucunuzdaki tüm RAM'leri kullanmamanızdır ( MBsorgularken belgenin tüm s'lerini RAM'e yüklemeniz gerekir.)

Bu nedenle sınır, ortak bir sistemdeki normal kullanılabilir RAM'in% bir kısmı ... bu da her geçen yıl büyümeye devam edecek.

MongoDB'de Dosya Saklama Hakkında Not

Belgeleri (veya dosyaları) depolamanız gerekiyorsa , verileri otomatik olarak bölümlere ayıracak ve size geri aktaracak GridFS API'sını16MB kullanabilirsiniz (böylece boyut sınırları / RAM ile ilgili sorunu önler).

Bir dosyayı tek bir belgede saklamak yerine, GridFS dosyayı parçalara veya parçalara böler ve her bir parçayı ayrı bir belge olarak saklar.

GridFS dosyaları depolamak için iki koleksiyon kullanır. Bir koleksiyon dosya yığınlarını, diğeri dosya meta verilerini depolar.

Bu yöntemi, görüntüleri, dosyaları, videoları vb. Bir SQL veritabanında olabildiğince veritabanında depolamak için kullanabilirsiniz. Bunu çok gigabayt video dosyalarını bile saklamak için kullandım.

Topluluktaki birçoğu performansla ilgili uyarılarla sınır tanımayı tercih etmez, iyi gerekçeli bir argüman için bu yoruma bakın: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin. system.issuetabpanels: comment-TabPanel # comment-22283

Benim düşüncem, baş geliştiriciler bu konuda inatçı çünkü erken bir zamanda önemli bir "özellik" olduğuna karar verdiler. Yakında bunu değiştirmeyecekler, çünkü duyguları kimsenin sorguladığı için yaralandı. Açık kaynak topluluklarındaki bir üründen uzaklaşan kişilik ve siyasetin başka bir örneği ama bu gerçekten sakat bir mesele değil.

Burada Google tarafından yönlendirilenlere açıklayıcı bir yanıt göndermek için.

Belge boyutu, alt belgeler, iç içe nesneler vb. Dahil olmak üzere belgedeki her şeyi içerir.

Yani bir belge:

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

Maksimum 16meg boyuta sahiptir.

Sbudocuments ve iç içe nesnelerin tümü, belgenin boyutuna göre sayılır.

Henüz belgenin içinde saklanan büyük dosyaları içermeyen sınırlama ile ilgili bir sorun görmedim. Büyük dosyaları depolamak / almakta çok verimli olan çeşitli veritabanları zaten vardır; bunlara işletim sistemleri denir. Veritabanı, işletim sistemi üzerinde bir katman olarak bulunur. Performans nedenleriyle bir NoSQL çözümü kullanıyorsanız, neden DB katmanını uygulamanız ve verileriniz arasına koyarak verilerinizin erişimine ek işlem yükü eklemek istesiniz ki?

JSON bir metin biçimidir. Dolayısıyla, verilerinize JSON üzerinden erişiyorsanız, ikili dosyalarınız varsa bu özellikle doğrudur, çünkü bunların uuencode, hexadecimal veya Base 64 olarak kodlanması gerekir.

ikili dosya <> JSON (kodlanmış) <> BSON (kodlanmış)

Belgenizdeki veri dosyasının yolunu (URL) koymak ve verileri ikili olarak tutmak daha verimli olur.

Bu uzunluğu bilinmeyen dosyaları gerçekten DB'nizde tutmak istiyorsanız, büyük olasılıkla büyük dosyalara erişildiğinde bunları GridFS'ye koymak ve eşzamanlılığınızı öldürme riskini almamak daha iyi olur.

BSON Belgeleri için İç İçe Derinlik: MongoDB, BSON belgeleri için 100'den fazla iç içe geçme düzeyini desteklemez.

Daha fazla bilgi vist

Belki bir blog yazısı -> yorum ilişkisini ilişkisel olmayan bir veritabanında saklamak gerçekten en iyi tasarım değildir.

Yine de blog yayınları için yorumları ayrı bir koleksiyonda saklamanız gerekir.

[Düzenle]

Daha fazla tartışma için aşağıdaki yorumlara bakın.

Https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1'e göre

Bir blog gönderisinin 16 MB belge sınırını aşabileceğini düşünüyorsanız, yorumları ayrı bir koleksiyona çıkarmalı ve yorumdan blog gönderisine başvurmalı ve uygulama düzeyinde bir katılma yapmalısınız.

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

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