문서 메뉴

문서 홈애플리케이션 개발MongoDB 매뉴얼

MongoDB 제한 및 임계값

이 페이지의 내용

  • MongoDB Atlas 한계
  • BSON 문서
  • 이름 지정 제한 사항
  • 이름 지정 경고
  • 네임스페이스
  • 인덱스
  • 정렬
  • 데이터
  • 복제본 세트
  • 샤드 클러스터
  • 운영
  • 세션

이 문서는 MongoDB 시스템의 엄격한 한도 및 비교적 유한 한도 모음을 제공합니다. 이 페이지의 한도는 별도로 지정하지 않는 한 다음 환경 모두에서 호스팅되는 배포에 적용됩니다.

  • MongoDB Atlas: 클라우드에서의 MongoDB 배포를 위한 완전 관리형 서비스

다음 제한 사항은 MongoDB Atlas에서 호스팅되는 배포에만 적용됩니다. 이러한 제한 사항 중 하나라도 조직에 문제가 되는 경우 Atlas 지원팀에 문의하세요.

구성 요소
Limit
멀티 리전 클러스터의샤드
12
단일 리전 클러스터의 샤드
50
멀티 리전 클러스터에 대한 리전 간 네트워크 권한
40. 또한 프로젝트 의 클러스터가 40 개를 초과하는 리전에 걸쳐 있는 경우 이 프로젝트에서는 멀티 리전 클러스터를 만들 수 없습니다.
복제본 세트 또는 샤드당 투표 가능 노드
7
Config 서버클러스터 계층 (최소 및 최대)
M30

MongoDB Atlas는 클러스터 계층과 클래스에 따라 동시 수신 연결을 제한합니다. MongoDB Atlas 연결 한도는 노드별로 적용됩니다. 샤딩된 클러스터의 경우에는 MongoDB Atlas 연결 한도가 mongos 라우터별로 적용됩니다. mongos 라우터의 수는 모든 샤드에서 합산된 복제본 세트 노드의 수와 같습니다.

읽기 설정 은 MongoDB Atlas가 특정 쿼리에 할당할 수 있는 총 연결 수에도 영향을 미칩니다.

지정된 클러스터 계층에 대한 MongoDB Atlas의 연결 한도는 다음과 같습니다.

참고

MongoDB Atlas는 MongoDB Atlas 서비스를 지원하기 위해 각 클러스터에 대한 소수의 연결을 예약합니다.

비공개 연결 을 통해 멀티클라우드 MongoDB Atlas 배포서버에 연결하는 경우, 연결 중인 동일한 클라우드 제공자의 노드에만 액세스할 수 있습니다. 이 클라우드 제공자는 해당 리전에 프라이머리 노드가 없을 수 있습니다. 이 경우 연결 문자열에 세컨더리 읽기 설정 모드를 지정하여 배포에 액세스해야 합니다.

현재 제공자에서 비공개 연결을 통해 멀티 클라우드 MongoDB Atlas 배포를 위한 모든 노드에 액세스해야 하는 경우, 다음 작업 중 하나를 수행해야 합니다.

  • 현재 제공업체의 VPN을 나머지 각 제공업체로 구성합니다.

  • 나머지 각 제공자에 대해 MongoDB Atlas에 대한 비공개 엔드포인트를 구성합니다.

단일 MongoDB Atlas 클러스터의 컬렉션 수에 대한 엄격한 한도는 없지만, 많은 수의 컬렉션과 인덱스를 제공하는 경우 클러스터의 성능이 저하될 수 있습니다. 컬렉션이 클수록 성능에 가해지는 영향도 커집니다.

MongoDB Atlas 클러스터 계층별로 권장되는 최대 컬렉션 및 인덱스 수의 총합은 다음과 같습니다.

MongoDB Atlas 클러스터 계층
권장 최대값
M10
5,000개의 컬렉션 및 인덱스
M20 / M30
10,000개의 컬렉션 및 인덱스
M40/+
100,000개의 컬렉션 및 인덱스

MongoDB Atlas 배포에는 다음과 같은 조직 및 프로젝트 한도가 있습니다.

구성 요소
Limit
MongoDB Atlas 프로젝트당 데이터베이스 사용자
100
MongoDB Atlas 프로젝트당 Atlas 사용자
500
MongoDB Atlas 조직당 Atlas 사용자
500
MongoDB Atlas 조직당 API 키
500
MongoDB Atlas 프로젝트당 목록 항목 액세스
200
MongoDB Atlas 팀당 사용자
250
MongoDB Atlas 프로젝트당 팀
100
MongoDB Atlas 조직당 팀
250
MongoDB Atlas 사용자당 팀
100
MongoDB Atlas 사용자당 조직
250
MongoDB Atlas 사용자당 연결된 조직
50
MongoDB Atlas 프로젝트당 클러스터
25
MongoDB Atlas 조직당 프로젝트
250
MongoDB Atlas 프로젝트당 사용자 지정 MongoDB 역할
100
데이터베이스 사용자당 할당된 역할
100
MongoDB Atlas 조직당 시간당 청구
$50
MongoDB Atlas 프로젝트당 연합 데이터베이스 인스턴스
25
MongoDB Atlas 프로젝트당 총 네트워크 피어링 연결
50. 또한 MongoDB Atlas는 프로젝트에 대해 선택한 CIDR 블록 및 리전 을 기반으로 네트워크 피어링 연결 당 노드 수를 제한합니다.
MongoDB Atlas 프로젝트당 보류 중인 네트워크 피어링 연결
25
리전당 AWS Private Link 주소 지정 가능 대상
50
리전당 Azure PrivateLink 주소 지정 가능 대상
150
MongoDB Atlas 프로젝트당 고유 샤드 키
40
MongoDB Atlas 프로젝트당 Atlas Data Lake 파이프라인
25
M0 MongoDB Atlas 프로젝트당 클러스터
1

MongoDB Atlas는 다음 구성 요소 레이블에 대해 길이를 제한하고 ReGex 요구 사항을 적용합니다.

구성 요소
글자 수 제한
RegEx 패턴
클러스터 이름
64 [1]
^([a-zA-Z0-9]([a-zA-Z0-9-]){0,21}(?<!-)([\w]{0,42}))$ [2]
프로젝트 이름
64
^[\p{L}\p{N}\-_.(),:&@+']{1,64}$ [3]
조직 이름
64
^[\p{L}\p{N}\-_.(),:&@+']{1,64}$ [3]
API 키 설명
250
[1] 피어링 전용 모드를 활성화 한 경우 클러스터 이름 문자 제한은 23 입니다.
[2] MongoDB Atlas는 클러스터 이름의 처음 23자를 사용합니다. 이러한 문자는 클러스터 프로젝트 내에서 고유해야 합니다. 23자 미만인 클러스터 이름의 마지막 문자는 하이픈(-)이 될 수 없습니다. 23자를 초과하는 클러스터 이름의 23번째 문자는 하이픈이 될 수 없습니다.
[3](1, 2) 조직 및 프로젝트 이름에는 유니코드 문자 또는 숫자와 문장 부호(-_.(),:&@+')를 포함할 수 있습니다.

MongoDB Atlas 서버리스 인스턴스, 무료 클러스터 및 공유 클러스터에는 추가 한도가 적용됩니다. 자세히 알아보려면 다음 리소스를 참조하세요.

일부 MongoDB 명령은 MongoDB Atlas에서 지원되지 않습니다. 또한 일부 명령은 MongoDB Atlas 무료 클러스터에서만 지원됩니다. 자세히 알아보려면 다음 리소스를 참조하세요.

BSON 문서 크기

최대 BSON 문서 크기는 16메가바이트입니다.

최대 문서 크기는 단일 문서가 과도한 양의 RAM을 사용하거나 전송 중에 과도한 대역폭을 사용하지 않도록 하는 데 도움이 됩니다. 최대 크기보다 큰 문서를 저장하기 위해 MongoDB는 GridFS API를 제공합니다. GridFS에 대한 자세한 내용은 mongofiles 및 해당 드라이버 설명서를 참조하세요.

BSON 문서의 중첩 깊이

MongoDB는 BSON 문서에 대해 100개 이하의 중첩 수준을 지원합니다. 각 객체 또는 배열은 수준을 추가합니다.

데이터베이스 이름의 대/소문자 사용

데이터베이스를 구분하기 위해 대/소문자를 사용하지 않도록 합니다. 예를 들어 salesDataSalesData와 같은 이름의 두 데이터베이스를 사용할 수 없습니다.

MongoDB에서 데이터베이스를 만든 후에는 데이터베이스를 참조할 때 일관된 대/소문자를 사용해야 합니다. 예를 들어, salesData 데이터베이스를 만드는 경우 salesdata 또는 SalesData와 같이 대/소문자를 번갈아 사용하여 참조하지 않도록 합니다.

Windows용 데이터베이스 이름에 대한 제한 사항

Windows에서 실행되는 MongoDB deployment의 경우 데이터베이스 이름에 다음 문자를 포함할 수 없습니다.

/\. "$*<>:|?

또한 데이터베이스 이름에는 null 문자를 포함할 수 없습니다.

Unix 및 Linux 시스템의 데이터베이스 이름에 대한 제한 사항

Unix 및 Linux 시스템에서 실행되는 MongoDB deployment의 경우 데이터베이스 이름에 다음 문자를 포함할 수 없습니다.

/\. "$

또한 데이터베이스 이름에는 null 문자를 포함할 수 없습니다.

데이터베이스 이름 길이

데이터베이스 이름은 비워둘 수 없으며 64자 미만이어야 합니다.

컬렉션 이름 제한

컬렉션 이름은 밑줄 또는 문자로 시작해야 하며 다음은 불가능합니다.

  • $가 포함되어 있습니다.

  • 빈 문자열입니다(예: "").

  • null 문자를 포함합니다.

  • system. 접두사로 시작합니다 (내부용으로만 사용됨).

컬렉션 이름에 밑줄 문자와 같은 특수 문자가 포함되어 있거나 숫자로 시작하는 경우 컬렉션에 액세스하려면 의 db.getCollection() 메서드 mongosh 또는 드라이버의 유사한 메서드를 사용합니다.

네임스페이스 길이:

featureCompatibilityVersion"4.4" 이상으로 설정된 경우 MongoDB는 collection/네임스페이스 제한을 255 바이트로 높입니다. collection 또는 뷰의 경우 네임스페이스에는 데이터베이스 이름, 점(.) 구분 기호, collection/뷰 이름(예: <database>.<collection>)이 포함됩니다.

필드 이름에 대한 제한 사항
  • 필드 이름에는 null 문자를 포함 할 수 없습니다.

  • 서버는 점(.)과 달러 기호($)가 포함된 필드 이름의 저장을 허용합니다.

  • MongoDB 5.0은 필드 이름에 ($) 및 (.)를 사용에 대한 지원을 개선했습니다.몇 가지 제한 사항이 있습니다. 자세한 내용은 필드 이름 고려 사항을 참조하십시오.

_id에 대한 제한 사항

필드 이름 _id는 프라이머리 키로 사용하기 위해 예약되어 있으며, 이 값은 컬렉션에서 고유해야 하고 변경할 수 없으며 배열 이외의 모든 유형이 될 수 있습니다. _id가 하위 필드를 포함하는 경우, 하위 필드 이름은 ($) 기호로 시작할 수 없습니다.

경고

이 섹션에서 설명하는 문제로 인해 데이터가 손실되거나 손상될 수 있으므로 주의하시기 바랍니다.

MongoDB 쿼리 언어는 필드 이름이 중복된 문서를 지원하지 않습니다. 일부 BSON 빌더는 필드 이름이 중복된 BSON 문서 생성을 지원할 수 있지만, 삽입이 성공했거나 성공한 것처럼 보이더라도 이러한 문서를 MongoDB에 삽입하는 것은 지원되지 않습니다. 예를 들어, 필드 이름이 중복된 BSON 문서를 MongoDB 드라이버를 통해 삽입하면 드라이버가 삽입 전에 중복 값을 조용히 삭제하거나 중복 필드가 포함된 유효하지 않은 문서가 삽입되는 결과를 초래할 수 있습니다. 이러한 문서에 대해 쿼리를 수행하면 임의적이고 일관성 없는 결과가 나올 수 있습니다.

MongoDB 5 부터 시작.0, 문서 필드 이름 앞에 달러($)를 붙일 수 있으며 마침표(.)를 포함할 수 있습니다. 그러나 mongoimportmongoexport 는 이러한 문자를 사용하는 필드 이름이 있는 일부 상황에서 예상대로 작동하지 않을 수 있습니다.

MongoDB 확장 JSON v2는 유형 래퍼와 유형 래퍼와 이름이 같은 필드를 구분할 수 없습니다. 해당 BSON 표현에 달러($) 접두사가 붙은 키가 포함될 수 있는 상황에서는 확장 JSON 형식을 사용하지 않도록 합니다. DBRef 메커니즘에는 해당 일반 규칙이 적용되지 않습니다.

필드 이름에 마침표(.)와 함께 mongoimportmongoexport 를 사용하는 것도 제한됩니다. CSV 파일은 마침표(.)를 사용하여 데이터 계층 구조를 나타내므로 필드 이름에 마침표(.)가 있으면 중첩 수준으로 잘못 해석됩니다.

달러($) 접두사가 붙은 필드 이름 또는 마침표(.)가 포함된 필드 이름을 사용할 때 MongoDB 5.0 이전 서버에서 이러한 필드 이름이 승인되지 않은 쓰기(쓰기 고려 w=0)와 함께 사용되는 경우 데이터가 손실될 가능성이 적습니다.

insert, updatefindAndModify 명령을 실행할 때 5.0과 호환되는 드라이버는 필드 이름 앞에 달러 기호($)가 붙거나 마침표(.)가 포함된 문서의 사용 제한을 제거합니다. 이러한 필드 이름은 이전 드라이버 버전에서 클라이언트 사이드 오류를 발생시켰습니다.

드라이버가 연결된 서버 버전에 관계없이 제한이 제거됩니다. 5.0 드라이버가 이전 서버로 문서를 보내는 경우 오류를 보내지 않고 문서가 거부됩니다.

네임스페이스 길이

featureCompatibilityVersion"4.4" 이상으로 설정된 경우 MongoDB는 collection/네임스페이스 제한을 255 바이트로 높입니다. collection 또는 뷰의 경우 네임스페이스에는 데이터베이스 이름, 점(.) 구분 기호, collection/뷰 이름(예: <database>.<collection>)이 포함됩니다.

다음도 참조하세요.

컬렉션당 인덱스 수

단일 컬렉션에는 64개 이하의 인덱스가 있을 수 있습니다.

복합 인덱스의 인덱싱된 필드 수

복합 인덱스에는 32개 이하의 필드가 포함될 수 있습니다.

쿼리는 텍스트 및 지리 공간적 인덱스를 모두 사용할 수 없습니다.

특수 텍스트 인덱스가 필요한 $text 쿼리를 다른 유형의 특수 인덱스가 필요한 쿼리 연산자와 결합할 수 없습니다. 예를 들어 $text 쿼리와 $near 연산자를 결합할 수 없습니다.

2dsphere 인덱스가 있는 필드는 도형만 보유할 수 있습니다.

2dsphere 인덱스가 있는 필드는 좌표 쌍 또는 GeoJSON 데이터 형식의 도형 데이터를 보유해야 합니다. 도형이 아닌 데이터가 있는 문서를 2dsphere 인덱스 필드에 삽입하거나 인덱스 필드에 도형이 아닌 데이터가 있는 컬렉션에 2dsphere 인덱스를 빌드하려고 하면 작업이 실패합니다.

WiredTiger 스토리지 엔진의 Covered Queries에서 반환된 NaN 값은 항상 double 형식입니다

인덱스에 포함되는 쿼리에서 반환된 필드 값이 NaN인 경우 해당 NaN 값의 유형은 항상 double입니다.

멀티키 인덱스

멀티키 인덱스 는 배열 필드에 대한 커버 쿼리를 할 수 없습니다.

지리 공간적 인덱스

지리 공간적 인덱스쿼리를 포함할 수 없습니다.

인덱스 빌드의 메모리 사용량

createIndexes 는 컬렉션에 하나 이상의 인덱스 작성을 지원합니다. createIndexes 는 디스크의 메모리와 임시 파일의 조합을 사용하여 인덱스 빌드를 완료합니다. createIndexes 의 메모리 사용량에 대한 기본 제한은 200 메가바이트이며, 단일 createIndexes 명령을 사용하여 구축된 모든 인덱스 간에 공유됩니다. 메모리 제한에 도달하면 createIndexes--dbpath 디렉토리 내의 _tmp 이라는 하위 디렉토리에 있는 임시 디스크 파일을 사용하여 빌드를 완료합니다.

maxIndexBuildMemoryUsageMegabytes 서버 매개변수를 설정하여 메모리 제한을 덮어쓸 수 있습니다. 메모리 제한을 높게 설정하면 인덱스 빌드가 더 빨리 완료될 수 있습니다. 하지만 이 제한을 시스템의 미사용 RAM에 비해 너무 높게 설정하면 메모리가 고갈되고 서버가 종료될 수 있습니다.

인덱스 빌드는 인덱스 생성 과 같은 사용자 명령이나 초기 동기화 와 같은 관리 프로세스를 통해 시작할 수 있습니다. 둘 다 maxIndexBuildMemoryUsageMegabytes 에서 설정한 한도의 적용을 받습니다.

초기 동기화 은 한 번에 하나의 collection만 채우며 메모리 제한을 초과할 위험이 없습니다. 그러나 사용자가 여러 데이터베이스의 여러 collection에 대한 인덱스 빌드를 동시에 시작하면 maxIndexBuildMemoryUsageMegabytes 에 설정된 제한보다 많은 양의 메모리를 사용할 수 있습니다.

인덱스 빌드가 복제본 세트와 복제본 세트 샤드가 포함된 샤드 클러스터에 미치는 영향을 최소화하려면 복제본 세트의 롤링 인덱스 빌드에 설명된 롤링 인덱스 빌드 절차를 사용합니다.

데이터 정렬 및 인덱스 유형

다음 인덱스 유형은 단순 이진 비교만 지원하며 데이터 정렬은 지원하지 않습니다:

단순 데이터 정렬이 아닌 collection에 text, 2d 또는 geoHaystack 인덱스를 만들려면 인덱스를 만들 때 {collation: {locale: "simple"} } 을 명시적으로 지정해야 합니다.

숨겨진 인덱스
최대 정렬 키 수

최대 32개의 키를 기준으로 정렬할 수 있습니다.

제한된 컬렉션의 최대 문서 수

create max 매개 변수를 사용하여 collection의 최대 문서 수를 지정하는 경우 제한은 2 32 문서보다 작아야 합니다. collection을 만들 때 최대 문서 수를 지정하지 않으면 문서 수에 제한이 없습니다.

복제본 세트의 멤버 수입니다.

복제본 세트에는 최대 50명의 구성원이 포함될 수 있습니다.

복제본 세트의 투표 구성원 수

복제본 세트에는 최대 7명의 투표 멤버가 있을 수 있습니다. 총 복제본 세트가 7명을 초과하는 멤버로 구성된 경우 투표권이 없는 멤버를 참조하세요.

자동 생성되는 Oplog의 최대 크기

oplog 크기를 명시적으로 지정하지 않으면(예: oplogSizeMB 또는 --oplogSize로) MongoDB는 50기가바이트 이하의 oplog를 생성합니다. [4]

[4] 2}가 삭제되는 것을 방지하기 위해 oplog가 구성된 크기 제한을 초과하여 커질 수 majority commit point 있습니다.

샤딩된 클러스터에는 여기에 설명된 제한 사항과 임계값이 있습니다.

샤드 환경에서 사용할 수 없는 작업

$where$where 함수에서 db 객체에 대한 참조를 허용하지 않습니다. 비 샤드형 컬렉션에서는 이런 일이 흔하지 않습니다.

geoSearch 명령은 샤딩된 환경에서는 지원되지 않습니다.

MongoDB 5.0 이전까지는 $lookup 단계의 from 파라미터에 샤드된 컬렉션을 지정할 수 없습니다.

샤딩된 클러스터에서 처리되는 쿼리

mongos에서 실행하는 경우 인덱스는 인덱스에 샤드 키가 포함된 경우에만 샤딩된 컬렉션에 대한 쿼리를 처리할 수 있습니다.

기존 collection 데이터 크기 샤딩

기존 collection은 해당 크기가 특정 제한을 초과하지 않는 경우에만 샤딩할 수 있습니다. 이러한 제한은 모든 샤드 키 값의 평균 크기와 구성된 청크 크기를 기반으로 추정할 수 있습니다.

중요

이러한 제한은 초기 샤딩 작업에만 적용됩니다. 샤딩을 성공적으로 활성화한 후에는 샤딩된 컬렉션을 원하는 크기로 늘릴 수 있습니다.

MongoDB는 생성 시 각 청크가 절반이 차도록 collection에 문서를 배포합니다. 다음 공식을 사용하여 이론적 최대 collection 크기를 계산합니다.

maxSplits = 16777216 (bytes) / <average size of shard key values in bytes>
maxCollectionSize (MB) = maxSplits * (chunkSize / 2)

참고

최대 BSON 문서 크기는 16MB 또는 16777216 바이트입니다.

모든 변환은 기본2 배율을 사용해야 합니다(예: 1024 킬로바이트 = 1 메가바이트).

maxCollectionSize 가 대상 collection보다 작거나 거의 같은 경우 청크 크기를 늘려 초기 샤딩이 성공적으로 수행되도록 합니다. 계산 결과가 목표 collection 크기에 너무 '가까운'지 확실하지 않은 경우 청크 크기를 늘리는 것이 좋습니다.

초기 샤딩에 성공한 후에는 필요에 따라 청크 크기를 줄일 수 있습니다. 나중에 청크 크기를 줄이면 모든 청크가 새 크기로 분할되는 데 시간이 걸릴 수 있습니다. 청크 크기 수정에 대한 지침 은 cluster에서 청크 크기 수정을 참조하세요.

이 표에서는 위에 설명된 공식을 사용하여 대략적인 최대 collection 크기를 보여 줍니다.

샤드 키 값의 평균 크기
512 바이트
256 바이트
128 바이트
64 바이트
최대 분할 수
32 일 768
65 일 536
131 일 072
262 일 144
최대 collection 크기(64 MB 청크 크기)
1 TB
2 TB
4TB
8 결핵
최대 collection 크기(128 MB 청크 크기)
2 TB
4TB
8 결핵
16 결핵
최대 collection 크기(256 MB 청크 크기)
4TB
8 결핵
16 결핵
32 결핵
샤드된 컬렉션의 단일 문서 수정 작업

justOne 또는 multi: false 옵션을 지정하는 분할된 컬렉션에 대해 updateremove() 작업 사용 방법:

  • 하나의 샤드만 대상으로 하는 경우 쿼리 사양에서 부분 샤드 키를 사용할 수 있습니다.

  • 쿼리 사양에서 샤드 키 또는 _id 필드를 제공할 수 있습니다.

샤드된 컬렉션의 고유 인덱스

고유 인덱스에 전체 샤드 키가 인덱스의 접두사로 포함된 경우를 제외하고, MongoDB는 샤드 간 고유 인덱스를 지원하지 않습니다. 이러한 상황에서 MongoDB는 단일 필드가 아닌 전체 키에 고유성을 적용합니다.

참조:

마이그레이션할 청크당 최대 문서 수

청크의 문서 수가 보다 크면 기본적으로 MongoDB는 청크를 이동할 수 1 없습니다. 구성된3 청크 크기 를 평균 문서 크기로 나눈 결과에 을db.collection.stats() 곱한 값입니다. 에는 avgObjSize collection의 평균 문서 크기를 나타내는 필드가 포함되어 있습니다.

너무 커서 마이그레이션할 수 없는 청크의 경우 MongoDB 4.4부터 다음을 수행합니다.

샤드 키 인덱스 유형

샤드 키 인덱스는 샤드 키의 오름차순 인덱스, 샤드 키로 시작하여 샤드 키의 오름차순을 지정하는 복합 인덱스 또는 해시 인덱스가 될 수 있습니다.

샤드 키 인덱스는 다음과 같을 수 없습니다.

샤드 키 선택

샤드 키 변경 옵션은 실행 중인 MongoDB 버전에 따라 다릅니다.

단조롭게 증가하는 샤드 키로 인해 삽입 처리량이 제한될 수 있음

삽입량이 많은 클러스터의 경우 키가 단조롭게 증가하거나 감소하는 샤드 키가 삽입 처리량에 영향을 미칠 수 있습니다. 샤드 키가 _id 필드인 경우 _id 필드의 기본값은 일반적으로 값이 증가하는 ObjectID라는 점에 유의하세요.

샤드 키가 단조롭게 증가하는 문서를 삽입할 때, 모든 삽입은 단일 샤드의 동일한 청크에 속합니다. 결국 시스템은 모든 쓰기 작업을 수신하는 청크 범위를 나누고 데이터를 더 균등하게 분배하기 위해 콘텐츠를 마이그레이션합니다. 그러나 클러스터는 언제든지 단일 샤드에만 삽입 작업을 지시하므로 삽입 처리량 병목 현상이 발생합니다.

클러스터 작업이 주로 읽기 작업 및 업데이트인 경우 이 제한은 클러스터에 영향을 미치지 않을 수 있습니다.

이 제약을 피하려면 해시된 샤드 키를 사용하거나 단조롭게 증가하거나 감소하지 않는 필드를 선택하세요.

해시된 샤드 키해시된 인덱스는 키 해시를 오름차순으로 저장합니다.

정렬 작업

MongoDB가 인덱스 또는 인덱스를 사용하여 정렬을 순서대로 가져올 수 없는 경우, MongoDB는 데이터에 대해 차단 정렬 작업을 수행해야 합니다. 이름은 SORT 단계에서 출력 문서를 반환하기 전에 모든 입력 문서를 읽고 해당 쿼리에 대한 데이터 흐름을 차단해야 한다는 요구 사항을 나타냅니다.

MongoDB에서 차단 정렬 작업에 100메가바이트 이상의 시스템 메모리를 사용해야 하는 경우 쿼리에서 cursor.allowDiskUse()지정하지 않는 한 MongoDB는 오류를 반환합니다. allowDiskUse()는 MongoDB가 차단 정렬 작업을 처리하는 동안 디스크의 임시 파일을 사용하여 100메가바이트 시스템 메모리 제한을 초과하는 데이터를 저장하도록 허용합니다.

정렬 및 인덱스 사용에 대한 자세한 내용은 정렬 및 인덱스 사용을 참조하세요.

집계 파이프라인 운영

각 개별 파이프라인 단계의 RAM 한도는 100메가바이트입니다. 기본적으로 단계가 이 제한을 초과하면 MongoDB에서 오류가 발생합니다. 일부 파이프라인 단계의 경우 allowDiskUse 옵션을 사용하여 집계 파이프라인 단계에서 임시 파일에 데이터를 쓰도록 설정하여 파이프라인 처리가 더 많은 공간을 차지하도록 할 수 있습니다.

$search 애그리게이션 단계는 별도의 프로세스에서 실행되므로 100 메가바이트의 RAM으로 제한되지 않습니다.

allowDiskUsetrue 일 때 디스크로 유출될 수 있는 단계의 예는 다음과 같습니다.

참고

파이프라인 단계는 각 파이프라인 단계가 문서를 가져와 처리한 다음 결과 문서를 출력하는 문서 스트림에서 작동합니다.

일부 단계에서는 들어오는 문서를 모두 처리할 때까지 문서를 출력할 수 없습니다. 이러한 파이프라인 단계는 들어오는 모든 문서가 처리될 때까지 단계 출력을 RAM에 보관해야 합니다. 따라서 이러한 파이프라인 단계에는 100MB 제한보다 더 많은 공간이 필요할 수 있습니다.

$sort 파이프라인 단계 중 하나의 결과가 한도를 초과하는 경우 $limit 단계를 추가하는 것을 고려하세요.

프로파일러 로그 메시지진단 로그 메시지 에는 메모리 제한으로 인해 애그리게이션 단계에서 임시 파일에 데이터를 쓴 경우 usedDisk 표시기가 포함됩니다.

집계 및 읽기 관심사
2D 지리 공간적 쿼리에서는 $or 연산자를 사용할 수 없습니다.
지리공간 쿼리

구형 쿼리의 경우 2dsphere 인덱스 결과를 사용합니다.

구형 쿼리에 2d 인덱스를 사용하면 극점을 감싸는 구형 쿼리에 2d 인덱스를 사용하는 것처럼 잘못된 결과가 발생할 수 있습니다.

지리 공간적 좌표
  • 유효한 경도 값은 -180~180입니다(둘 모두 포함).

  • 유효한 위도 값은 -90~90입니다(둘 모두 포함).

GeoJSON 다각형의 면적

$geoIntersects 또는 $geoWithin 의 경우, 면적이 단일 반구보다 큰 단일 고리 다각형을 지정하는 경우 the custom MongoDB coordinate reference system in the $geometry 표현식을 포함하십시오. 그렇지 않으면 $geoIntersects 또는 $geoWithin 가 보완 도형을 쿼리합니다. 반구보다 큰 면적을 가진 다른 모든 GeoJSON 다각형의 경우 $geoIntersects 또는 $geoWithin 이 보완 도형을 쿼리합니다.

다중 문서 트랜잭션

다중 문서 트랜잭션의 경우:

  • 트랜잭션에서 컬렉션과 인덱스를 생성할 수 있습니다. 자세한 내용은 트랜잭션에서 컬렉션 및 인덱스 생성하기를 참조하세요

  • 트랜잭션에 사용되는 컬렉션은 서로 다른 데이터베이스에 있을 수 있습니다.

    참고

    샤드 간 쓰기 트랜잭션에서는 새 컬렉션을 생성할 수 없습니다. 예를 들어, 하나의 샤드에서 기존 컬렉션에 쓰고 다른 샤드에서 암시적으로 새 컬렉션을 생성하는 경우, MongoDB는 동일한 트랜잭션에서 두 작업을 모두 수행할 수 없습니다.

  • 제한된 컬렉션에는 쓸 (write) 수 없습니다.

  • 고정 사이즈 컬렉션에서 읽을 때는 읽기 고려 "snapshot"을 사용할 수 없습니다. (MongoDB 5.0부터 도입됨)

  • config, admin 또는 local 데이터베이스의 컬렉션을 읽고 쓸 수 없습니다.

  • system.* 컬렉션에 쓸 수 없습니다.

  • explain 또는 이와 유사한 명령을 사용하여 지원되는 작업의 쿼리 계획을 반환할 수 없습니다.

  • 트랜잭션 외부에서 생성된 커서의 경우 트랜잭션 내부에서 getMore을(를) 호출할 수 없습니다.

  • 트랜잭션에서 생성된 커서의 경우 트랜잭션 외부에서 getMore를 호출할 수 없습니다.

트랜잭션에서 허용되지 않는 작업은 다음과 같습니다.

거래에는 transactionLifetimeLimitSeconds에 명시된 바와 같이 평생 제한이 있습니다. 기본값은 60초입니다.

쓰기 명령 배치 제한 크기

100,000 서버에 대한 단일 요청으로 정의된 단일 배치 작업에서 쓰기가 허용됩니다.

버전 3.6에서 변경됨: 쓰기 한도가 1,000에서 100,000으로 증가합니다. 이 제한은 레거시 OP_INSERT 메시지에도 적용됩니다.

Bulk() mongosh 및 드라이버의 유사한 메서드의 작업에는 이 제한이 없습니다.

조회수

뷰 정의 pipeline 에는 $out 또는 $merge 단계를 포함할 수 없습니다. 뷰 정의에 중첩된 파이프라인이 포함된 경우(예: 뷰 정의에 $lookup 또는 $facet 단계가 포함된 경우) 이 제한은 중첩된 파이프라인에도 적용됩니다.

보기에는 다음과 같은 작업 제한이 있습니다.

  • 보기는 읽기 전용입니다.

  • 의 이름은 바꿀 수 없습니다.

  • 뷰에 대한 find() 작업은 다음 프로젝션 연산자를 지원하지 않습니다.

  • 보기는 텍스트 검색을 지원하지 않습니다.

  • 뷰는 맵 축소 작업을 지원하지 않습니다.

프로젝션 제한 사항
$-접두사 필드 경로 제한
find()findAndModify() 프로젝트는 DBRef 필드를 제외하고 $ 로 시작하는 필드를 프로젝트할 수 없습니다. 예를 들어 다음 작업은 유효하지 않습니다:
db.inventory.find( {}, { "$instock.warehouse": 0, "$item": 0, "detail.$price": 1 } )
$ 위치 연산자 배치 제한
$ 프로젝션 연산자는 필드 경로의 끝에만 나타날 수 있습니다(예: "field.$" 또는 "fieldA.fieldB.$". 예를 들어 다음 작업은 유효하지 않습니다.
db.inventory.find( { }, { "instock.$.qty": 1 } )
이 문제를 해결하려면 $ 프로젝션 연산자 뒤에 오는 필드 경로의 구성 요소를 제거합니다.
빈 필드 이름 프로젝션 제한
find()findAndModify() 프로젝션에는 빈 필드 이름의 프로젝션을 포함할 수 없습니다. 예를 들어 다음 작업은 유효하지 않습니다.
db.inventory.find( { }, { "": 0 } )
이전 버전에서 MongoDB는 빈 필드의 포함/제외를 존재하지 않는 필드의 프로젝션과 동일하게 처리합니다.
경로 충돌: 내장된 문서 및 해당 필드
내장된 문서의 필드가 있는 내장된 문서는 프로젝트할 수 없습니다. 예를 들어, 필드가 포함된 문서가 있는 collection 를 생각해 보겠습니다.inventory size
{ ..., size: { h: 10, w: 15.25, uom: "cm" }, ... }
다음 작업은 size 문서와 size.uom 필드를 모두 프로젝트하려고 시도하기 때문에 Path collision 오류와 함께 실패합니다.
db.inventory.find( {}, { size: 1, "size.uom": 1 } )
이전 버전에서는 내장된 문서와 해당 필드 사이의 마지막 프로젝션이 프로젝션을 결정합니다.
  • 내장된 문서의 프로젝션이 해당 필드의 모든 프로젝션 다음에 오는 경우 MongoDB는 내장된 문서를 프로젝트합니다. 예를 들어 프로젝션 문서 { "size.uom": 1, size: 1 }은 프로젝션 문서 { size: 1 }과 동일한 결과를 생성합니다.

  • 내장된 문서의 프로젝션이 해당 필드의 프로젝션보다 먼저 오면 MongoDB는 지정된 필드를 프로젝트합니다. 예를 들어 프로젝션 문서 { "size.uom": 1, size: 1, "size.h": 1 }은 프로젝션 문서 { "size.uom": 1, "size.h": 1 }과 동일한 결과를 생성합니다.

경로 충돌: 배열 및 포함된 필드의 $slice 충돌
find()findAndModify() 프로젝션은 배열의 $slice 와 배열에 포함된 필드를 모두 포함할 수 없습니다. 예를 들어, 배열 필드 instock 를 포함하는 collection inventory 을 생각해 보겠습니다.
{ ..., instock: [ { warehouse: "A", qty: 35 }, { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ], ... }
다음 작업이 Path collision 오류와 함께 실패합니다.
db.inventory.find( {}, { "instock": { $slice: 1 }, "instock.warehouse": 0 } )
이전 버전에서 프로젝션은 두 프로젝션을 모두 적용하고 instock 배열의 첫 번째 요소($slice: 1)를 반환하지만 프로젝션된 요소에서 warehouse 필드를 억제합니다. MongoDB 4.4부터는 동일한 결과를 얻으려면 $project 로 구성된 db.collection.aggregate() 메서드를 사용하십시오.
$ 위치 연산자 및 $slice 제한
find()findAndModify() 프로젝션은 $slice 프로젝션 표현식을 $ 프로젝션 표현식의 일부로 포함할 수 없습니다. 예를 들어, 다음 작업은 유효하지 않습니다.
db.inventory.find( { "instock.qty": { $gt: 25 } }, { "instock.$": { $slice: 1 } } )
이전 버전에서 MongoDB는 쿼리 조건과 일치하는 instock 배열의 첫 번째 요소 (instock.$)를 반환합니다. 즉, 위치 프로젝션 "instock.$" 이(가) 우선하고 $slice:1 은(는) 작동하지 않습니다. "instock.$": { $slice: 1 } 은(는) 다른 문서 필드를 제외하지 않습니다.
세션 및 $external 사용자 이름 제한

$external 인증 사용자(Kerberos, LDAP 또는 x.509 사용자)와 함께 클라이언트 세션 및 인과적 일관성 보장 을 사용하려면 사용자 이름이 10k 바이트를 초과할 수 없습니다.

세션 유휴 시간 초과

30분 동안 읽기 또는 쓰기 작업이 없거나 이 임계값 내에서 refreshSessions를 사용하여 새로 고쳐지지 않는 세션은 만료된 것으로 표시되며 언제든지 MongoDB 서버에서 닫을 수 있습니다. 세션을 닫으면 진행 중인 모든 작업이 종료되고 세션과 연결된 커서가 열립니다. 여기에는 noCursorTimeout() 또는 30분보다 큰 maxTimeMS()로 구성된 커서가 포함됩니다.

db.collection.find()를 발행하는 애플리케이션을 고려하십시오. 서버는 find()cursor.batchSize()로 정의된 문서 일괄 처리와 함께 커서를 반환합니다. 애플리케이션이 서버에서 새로운 문서 배치를 요청할 때마다 세션이 새로 고쳐집니다. 그러나 애플리케이션이 현재 문서 배치를 처리하는 데 30분 이상 소요되면 세션이 만료되고 닫힌 것으로 표시됩니다. 애플리케이션이 다음 문서 배치를 요청하면 세션이 닫힐 때 커서가 종료되므로 서버는 오류를 반환합니다.

커서를 반환하는 작업의 경우 커서가 30분 이상 유휴 상태일 수 있는 경우 Mongo.startSession()를 사용하여 명시적 세션 내에서 작업을 실행하고 refreshSessions 명령을 사용하여 세션을 주기적으로 새로 고칩니다. 예를 들면 다음과 같습니다.

var session = db.getMongo().startSession()
var sessionId = session
sessionId // show the sessionId
var cursor = session.getDatabase("examples").getCollection("data").find().noCursorTimeout()
var refreshTimestamp = new Date() // take note of time at operation start
while (cursor.hasNext()) {
// Check if more than 5 minutes have passed since the last refresh
if ( (new Date()-refreshTimestamp)/1000 > 300 ) {
print("refreshing session")
db.adminCommand({"refreshSessions" : [sessionId]})
refreshTimestamp = new Date()
}
// process cursor normally
}

예시 작업에서 db.collection.find() 메서드는 명시적 세션과 연결됩니다. 커서는 유휴 상태일 때 서버가 커서를 닫는 것을 방지하기 위해 noCursorTimeout()으로 구성됩니다. while 루프에는 refreshSessions를 사용하여 5분마다 세션을 새로 고치는 블록이 포함되어 있습니다. 세션은 30분의 유휴 시간 제한을 초과하지 않으므로 커서는 무기한 열린 상태로 유지될 수 있습니다.

MongoDB 드라이버의 경우, 세션 생성에 대한 지침과 구문은 드라이버 설명서를 참조하세요.

← MongoDB 서버 매개변수