MongoDB BSON 문서 크기 제한 이해

MongoDB BSON 문서 크기 제한 이해

---

MongoDB에서 확실한 가이드 :

4MB보다 큰 문서 (BSON으로 변환시)는 데이터베이스에 저장할 수 없습니다. 이것은 다소 임의적 인 한계입니다 (향후에 제기 될 수 있음). 주로 스키마 설계가 잘못되는 것을 방지하고 일관된 성능을 보장합니다.

이 제한을 이해하지 못합니다. 이는 4MB보다 큰 주석이 많은 블로그 게시물이 포함 된 문서를 단일 문서로 저장할 수 없음을 의미합니까?

또한 이것은 중첩 문서도 계산합니까?

변경 사항을 감사하는 문서를 원한다면 어떻게해야합니까? (결국 4MB를 초과하여 커질 수 있습니다.)

누군가가 이것을 올바르게 설명하기를 바랍니다.

나는 방금 MongoDB (내가 배우고있는 첫 번째 nosql 데이터베이스)에 대해 읽기 시작했다.

감사합니다.

---

우선, 이것은 실제로 다음 버전에서 8MB또는 16MB... 에서 제기되고 있지만, 이것을 관점으로 생각하면 10gen (MongoDB를 개발 한 사람)의 Eliot가 가장 잘 생각합니다.

편집 : 크기는 공식적 으로16MB

예를 들어, "War of the Worlds"의 전체 압축되지 않은 텍스트는 364k (html)입니다. http://www.gutenberg.org/etext/36

귀하의 블로그 게시물이 그처럼 많은 의견을 가진 것이라면, 나는 그것을 읽지 않을 것입니다 :)

트랙백의 경우 1MB를 전용으로 사용하면 10k 이상 (아마도 20k에 가깝게)을 가질 수 있습니다.

정말 기괴한 상황을 제외하고는 잘 작동합니다. 예외적 인 경우 나 스팸의 경우, 어쨌든 20MB 객체를 원한다고 생각하지 않습니다. 트랙백 상한을 15k 정도로 설정하면 성능에 관계없이 많은 의미가 있다고 생각합니다. 또는 적어도 특별한 경우가 발생합니다.

엘리엇

나는 당신이 한계에 도달하기가 매우 어려울 것이라고 생각합니다 ... 그리고 시간이 지남에 따라 업그레이드하면 ... 더 적은 걱정을해야합니다.

제한의 주요 요점은 서버에서 모든 RAM을 사용하지 않는 것입니다 ( MB문의 할 때 문서의 모든 RAM을 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 : comment-tabpanel # comment-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, 16 진 또는 Base 64로 인코딩되어야하기 때문에 이진 파일이있는 경우 특히 그렇습니다. 변환 경로는 다음과 같습니다.

이진 파일 <> JSON (인코딩) <> BSON (인코딩)

문서의 데이터 파일에 대한 경로 (URL)를 저장하고 데이터 자체를 이진으로 유지하는 것이 더 효율적입니다.

실제로 알 수없는 길이의 파일을 DB에 보관하려면 GridFS에 파일을 저장하고 큰 파일에 액세스 할 때 동시성을 종료 할 위험이없는 것이 좋습니다.

---

BSON 문서에 대한 중첩 깊이 : MongoDB는 BSON 문서에 대해 100 개 이하의 중첩 수준을 지원합니다.

더 많은 정보 vist

---

Perhaps storing a blog post -> comments relation in a non-relational database is not really the best design.

You should probably store comments in a separate collection to blog posts anyway.

[edit]

See comments below for further discussion.

---

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

If you expect that a blog post may exceed the 16Mb document limit, you should extract the comments into a separate collection and reference the blog post from the comment and do an application-level join.

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

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

참고URL : https://stackoverflow.com/questions/4667597/understanding-mongodb-bson-document-size-limit