ทำความเข้าใจกับขีด จำกัด ขนาดของเอกสาร MongoDB BSON

จาก MongoDB คำแนะนำการแตกหัก:

เอกสารที่มีขนาดใหญ่กว่า 4MB (เมื่อแปลงเป็น BSON) ไม่สามารถบันทึกลงในฐานข้อมูล นี่เป็นข้อ จำกัด ที่ค่อนข้าง จำกัด (และอาจเพิ่มขึ้นในอนาคต) เป็นส่วนใหญ่เพื่อป้องกันการออกแบบสคีมาที่ไม่ดีและให้ประสิทธิภาพที่สอดคล้องกัน

ฉันไม่เข้าใจขีด จำกัด นี้หมายความว่าเอกสารที่มีโพสต์บล็อกที่มีความคิดเห็นจำนวนมากซึ่งมีขนาดใหญ่กว่า 4MB ไม่สามารถจัดเก็บเป็นเอกสารเดียวได้หรือไม่

สิ่งนี้จะนับรวมเอกสารที่ซ้อนกันด้วยหรือไม่

ถ้าฉันต้องการเอกสารที่ตรวจสอบการเปลี่ยนแปลงค่า (ในที่สุดจะเติบโตเกินขีด จำกัด 4MB)

หวังว่าจะมีคนอธิบายเรื่องนี้อย่างถูกต้อง

ฉันเพิ่งเริ่มอ่านเกี่ยวกับ MongoDB (ฐานข้อมูล nosql แรกที่ฉันเรียนรู้)

ขอบคุณ.

ก่อนอื่นสิ่งนี้กำลังถูกยกระดับในรุ่นถัดไป8MBหรือ16MB... แต่ฉันคิดว่าจะนำเสนอในมุมมองของเอเลียตจาก 10gen (ผู้พัฒนา MongoDB) ทำให้ดีที่สุด:

แก้ไข: ขนาดได้รับการ'ยก' อย่างเป็นทางการเป็น16MB

ดังนั้นในตัวอย่างบล็อกของคุณ 4MB นั้นเป็นจำนวนมาก .. ตัวอย่างเช่นข้อความที่ไม่มีการบีบอัดแบบเต็มของ "War of the Worlds" มีเพียง 364k (html): http://www.gutenberg.org/etext/36

หากการโพสต์บล็อกของคุณนั้นยาวมากพร้อมกับความคิดเห็นมากมายฉันจะไม่อ่าน :)

สำหรับ trackbacks หากคุณทุ่มเท 1MB ไปคุณสามารถมีมากกว่า 10k (อาจใกล้ถึง 20k)

ดังนั้นยกเว้นสถานการณ์ที่แปลกประหลาดอย่างแท้จริงมันจะใช้งานได้ดี และในกรณียกเว้นหรือสแปมฉันไม่คิดว่าคุณต้องการวัตถุขนาด 20mb อยู่ดี ฉันคิดว่าการกำหนด trackbacks เป็น 15k หรือมากกว่านั้นสมเหตุสมผลมากไม่ว่าจะเป็นเรื่องอะไรสำหรับการแสดง หรืออย่างน้อยปลอกพิเศษถ้ามันเคยเกิดขึ้น

-Eliot

ฉันคิดว่าคุณจะกดยากที่จะถึงขีด จำกัด ... และเมื่อเวลาผ่านไปถ้าคุณอัพเกรด ... คุณจะต้องกังวลน้อยลง

จุดหลักของข้อ จำกัด คือคุณไม่ต้องใช้ RAM ทั้งหมดในเซิร์ฟเวอร์ของคุณ (เนื่องจากคุณจำเป็นต้องโหลดMBเอกสารทั้งหมดลงใน RAM เมื่อคุณทำการค้นหา)

ดังนั้นขีด จำกัด คือ RAM บางส่วนที่สามารถใช้งานได้ปกติบนระบบทั่วไป ... ซึ่งจะเพิ่มขึ้นทุกปี

หมายเหตุเกี่ยวกับการจัดเก็บไฟล์ใน MongoDB

หากคุณต้องการจัดเก็บเอกสาร (หรือไฟล์) ที่มีขนาดใหญ่กว่าที่16MBคุณสามารถใช้GridFS APIซึ่งจะแบ่งข้อมูลออกเป็นเซ็กเมนต์โดยอัตโนมัติและสตรีมกลับไปที่คุณ (เพื่อหลีกเลี่ยงปัญหาเรื่องขนาด จำกัด / RAM)

แทนที่จะเก็บไฟล์ไว้ในเอกสารเดียว GridFS แบ่งไฟล์ออกเป็นส่วน ๆ หรือชิ้นส่วนและเก็บแต่ละอันเป็นเอกสารแยกต่างหาก

GridFS ใช้สองคอลเลกชันในการจัดเก็บไฟล์ คอลเลกชันหนึ่งเก็บส่วนไฟล์และเมทาดาทาไฟล์เก็บอื่น ๆ

คุณสามารถใช้วิธีนี้ในการจัดเก็บรูปภาพไฟล์วิดีโอ ฯลฯ ในฐานข้อมูลได้มากเท่าที่คุณจะทำได้ในฐานข้อมูล SQL ฉันใช้สิ่งนี้เพื่อจัดเก็บไฟล์วิดีโอหลายกิกะไบต์

หลายคนในชุมชนไม่ต้องการ จำกัด คำเตือนเกี่ยวกับประสิทธิภาพการทำงานให้ดูความคิดเห็นนี้เพื่อหาข้อโต้แย้งที่สมเหตุสมผล: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin system.issuetabpanels: ความคิดเห็น-tabpanel # คิดเห็น-22283

นักพัฒนาลีดเดอร์ของฉันดื้อรั้นเกี่ยวกับปัญหานี้เพราะพวกเขาคิดว่ามันเป็น "คุณสมบัติ" ที่สำคัญในช่วงต้น พวกเขาจะไม่เปลี่ยนแปลงตลอดเวลาในไม่ช้าเพราะความรู้สึกเจ็บปวดที่ใคร ๆ ก็ถาม อีกตัวอย่างหนึ่งของบุคลิกภาพและการเมืองที่เบี่ยงเบนจากผลิตภัณฑ์ในชุมชนโอเพ่นซอร์ส แต่นี่ไม่ใช่ปัญหาที่ทำให้หมดอำนาจอย่างแท้จริง

หากต้องการโพสต์คำตอบเพื่อความกระจ่างที่นี่สำหรับผู้ที่เข้ามาที่นี่โดย Google

ขนาดเอกสารรวมทุกอย่างในเอกสารรวมถึงเอกสารย่อยวัตถุที่ซ้อนกันเป็นต้น

ดังนั้นเอกสารของ:

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

มีขนาดสูงสุด 16meg

Sbudocuments และวัตถุที่ซ้อนกันจะถูกนับรวมกับขนาดของเอกสาร

ฉันยังไม่เห็นปัญหาเกี่ยวกับขีด จำกัด ที่ไม่เกี่ยวข้องกับไฟล์ขนาดใหญ่ที่เก็บอยู่ในเอกสารนั้น มีฐานข้อมูลที่หลากหลายซึ่งมีประสิทธิภาพมากในการจัดเก็บ / ดึงไฟล์ขนาดใหญ่ พวกเขาเรียกว่าระบบปฏิบัติการ ฐานข้อมูลมีอยู่เป็นชั้นบนระบบปฏิบัติการ หากคุณกำลังใช้โซลูชัน NoSQL เพื่อเหตุผลด้านประสิทธิภาพเหตุใดคุณจึงต้องการเพิ่มการประมวลผลเพิ่มเติมเพื่อเข้าถึงข้อมูลของคุณโดยการใส่เลเยอร์ DB ระหว่างแอปพลิเคชันและข้อมูลของคุณ

JSON เป็นรูปแบบข้อความ ดังนั้นหากคุณเข้าถึงข้อมูลของคุณผ่าน JSON สิ่งนี้จะเป็นจริงโดยเฉพาะอย่างยิ่งถ้าคุณมีไฟล์ไบนารีเพราะจะต้องมีการเข้ารหัสในรูปแบบ uuencode เลขฐานสิบหกหรือฐาน 64 เส้นทางการแปลงอาจมีลักษณะเช่นนี้

ไฟล์ไบนารี <> JSON (เข้ารหัส) <> BSON (เข้ารหัส)

การใส่พา ธ (URL) ไปยังไฟล์ข้อมูลในเอกสารของคุณจะมีประสิทธิภาพมากกว่าและเก็บข้อมูลไว้ในรูปแบบไบนารี

หากคุณต้องการเก็บไฟล์เหล่านี้ในความยาวที่ไม่รู้จักในฐานข้อมูลของคุณจริงๆคุณน่าจะดีกว่าที่จะวางไฟล์เหล่านี้ใน GridFS และไม่เสี่ยงต่อการทำลายไฟล์พร็อพเพอร์ตี้เมื่อมีการเข้าถึงไฟล์ขนาดใหญ่

ความลึกแบบซ้อนสำหรับเอกสาร BSON: MongoDB รองรับการซ้อนกันไม่เกิน 100 ระดับสำหรับเอกสาร BSON

ดูข้อมูลเพิ่มเติมเพิ่มเติม

บางทีการจัดเก็บโพสต์บล็อก -> ความคิดเห็นเกี่ยวกับความสัมพันธ์ในฐานข้อมูลที่ไม่เกี่ยวข้องนั้นไม่ใช่การออกแบบที่ดีที่สุดจริงๆ

คุณควรเก็บความคิดเห็นไว้ในชุดสะสมแยกต่างหากในบล็อกโพสต์

[แก้ไข]

ดูความคิดเห็นด้านล่างสำหรับการสนทนาเพิ่มเติม

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

หากคุณคาดว่าโพสต์บล็อกอาจเกินขีด จำกัด เอกสาร 16Mb คุณควรแยกข้อคิดเห็นออกเป็นคอลเล็กชันแยกต่างหากและอ้างอิงโพสต์บล็อกจากความคิดเห็นและเข้าร่วมระดับแอปพลิเคชัน

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

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