MongoDB BSON 문서 크기 제한에 대해

MongoDB BSON 문서 크기 제한에 대해

MongoDB 최종 가이드:

4MB보다 큰 문서(BSON으로 변환된 경우)는 데이터베이스에 저장할 수 없습니다.이는 다소 자의적인 제한(향후 발생할 수 있음)으로, 대부분 잘못된 스키마 설계를 방지하고 일관된 성능을 보장하기 위한 것입니다.

이 제한을 이해할 수 없습니다만, 4MB가 넘는 블로그 투고가 많은 문서는 하나의 문서로 저장할 수 없는 것입니까?

또한 중첩된 문서도 계산됩니까?

값의 변경 사항을 감사하는 문서가 필요한 경우 어떻게 해야 합니다.(최종적으로는 4MB 제한을 초과하여 증가할 수 있습니다.)

누군가 이것을 정확하게 설명해주길 바란다.

MongoDB(처음 배우는 nosql 데이터베이스)에 대해 읽기 시작했습니다.

감사해요.

은 실제로 다음 , 것, 음, 음, 음, 음, 음, 음, 음, first, first, first, first, first, first, first, first, first, first, first, first, first, first, first in, in,8MB ★★★★★★★★★★★★★★★★★」16MB 이 해 보면, 과 같이 .하지만, 이 점을 고려해 보면, 10gen(MongoDB를 개발한)의 Eliot씨는 다음과 같이 말하고 있습니다.

편집: 사이즈가 공식적으로 '업그레이드'되었습니다.16MB

당신의 블로그 예에서 4MB는 사실 많은 양입니다.예를 들어, "War of the Worlds"의 전체 압축 해제 텍스트는 364k(표준)에 불과합니다.http://www.gutenberg.org/etext/36

당신의 블로그 투고가 그렇게 길면, 나는 그것을 읽지 않을 것입니다:)

트랙백의 경우, 1MB를 전용으로 하면, 10,000(아마도 20,000에 가까운 용량)이 넘을 가능성이 있습니다.

그래서 정말 이상한 상황을 제외하고는, 잘 될 거야.그리고 예외적인 경우나 스팸의 경우, 어쨌든 20MB 오브젝트는 원하지 않을 것입니다.트랙백을 15k 정도로 제한하는 것은 퍼포먼스에 관계없이 매우 타당하다고 생각합니다.아니면 최소한 그런 일이 생기면 특별한 케이스라도요

-엘리오트

한계에 도달하는 것은 매우 힘들 것이라고 생각합니다만, 시간이 지남에 따라 업그레이드하면...점점 더 걱정을 덜게 될 거야

입니다(모든 RAM을 해야 하기 에 RAM을 로드해야 합니다).MB 시 으로 변환됩니다 (RAM)

따라서 일반 시스템에서 사용할 수 있는 일반 RAM의 %가 한계입니다.전년 동기 대비 계속 증가할 것입니다.

MongoDB에 파일 저장에 관한 주의사항

파일16MBGridFS API를 사용하면 데이터를 세그먼트로 자동 분할하여 사용자에게 스트리밍할 수 있습니다(따라서 크기 제한/RAM 문제를 피할 수 있습니다.

GridFS는 단일 문서에 파일을 저장하는 대신 파일을 부분 또는 청크로 나누고 각 청크를 개별 문서로 저장합니다.

GridFS는 2개의 컬렉션을 사용하여 파일을 저장합니다.한 컬렉션에는 파일 청크가 저장되고 다른 컬렉션에는 파일 메타데이터가 저장됩니다.

이 방법을 사용하여 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 }, {}] }
  ]
}

최대 사이즈는 16 MB입니다.

하위 문서 및 중첩된 오브젝트는 모두 문서 크기로 계산됩니다.

문서 자체에 대용량 파일이 저장되어 있지 않은 제한에 대해서는 아직 문제를 발견하지 못했습니다.대용량 파일 저장/검색에 매우 효율적인 다양한 데이터베이스가 이미 있습니다. 이를 운영 체제라고 합니다.데이터베이스는 운영 체제의 계층으로 존재합니다.성능상의 이유로 NoSQL 솔루션을 사용하는 경우 애플리케이션과 데이터 사이에 DB 계층을 배치하여 데이터 액세스에 처리 오버헤드를 추가하는 이유는 무엇입니까?

JSON은 텍스트 형식입니다.따라서 JSON을 통해 데이터에 액세스하는 경우 바이너리 파일은 uuencode, 16진수 또는 Base 64로 인코딩해야 하므로 특히 그렇습니다.변환 경로는 다음과 같습니다.

바이너리 파일<>JSON(인코딩)<>BSON(인코딩)

데이터 파일에 대한 경로(URL)를 문서에 넣고 데이터 자체를 바이너리로 유지하는 것이 더 효율적입니다.

이러한 알 수 없는 길이의 파일을 DB에 보관하려면 GridFS에 저장하고 대용량 파일에 액세스할 때 동시성을 잃지 않는 것이 좋습니다.

BSON 문서의 중첩 깊이:MongoDB는 BSON 문서에 대해 최대 100레벨의 네스트를 지원합니다.

상세 정보 vist

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')
  }
]

블로그 투고 -> 코멘트 관계를 비관계형 데이터베이스에 저장하는 것은 최선의 설계가 아닐 수 있습니다.

어쨌든 코멘트는 블로그 투고용으로 다른 컬렉션에 저장해야 합니다.

[편집]

상세한 것에 대하여는, 이하의 코멘트를 참조해 주세요.

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