문서 메뉴
문서 홈
/
MongoDB 매뉴얼
/

FAQ: MongoDB 스토리지

이 페이지의 내용

  • 스토리지 엔진 기본 사항
  • 복제본 세트에 스토리지 엔진을 혼합할 수 있나요?
  • 스토리지 권장 사항
  • 와이어드타이거 스토리지 엔진
  • 데이터 스토리지 진단

이 문서는 MongoDB의 스토리지 시스템과 관련된 일반적인 질문에 대한 답변입니다.

스토리지 엔진은 메모리와 디스크 모두에서 데이터가 저장되는 방식을 관리하는 데이터베이스의 일부입니다. 많은 데이터베이스가 여러 스토리지 엔진을 지원하며, 서로 다른 각각의 엔진이 특정 워크로드별로 더 나은 성능을 발휘합니다. 예를 들어, 한 스토리지 엔진은 읽기 위주의 워크로드에 더 나은 성능을 제공하고, 다른 스토리지 엔진은 쓰기 작업에 더 높은 처리량을 지원할 수 있습니다.

다음도 참조하세요.

스토리지 엔진

예. 서로 다른 스토리지 엔진(WiredTiger 및 인메모리)을 사용하는 복제본 세트 멤버를 가질 수 있습니다

결합된 컬렉션 및 인덱스 수가 100,000개를 초과하면 클러스터 성능이 저하될 수 있습니다. 또한 많은 대규모 컬렉션이 소규모 컬렉션보다 성능에 더 큰 영향을 미칩니다.

예. 예시를 보여드리겠습니다.

압축된 데이터와 압축되지 않은 데이터의 비율은 데이터 및 사용된 압축 라이브러리에 따라 달라집니다. 기본적으로 WiredTiger의 컬렉션 데이터는 Snappy block 압축을 사용하며, zlibzstd 압축도 사용할 수 있습니다. 인덱스 데이터는 기본적으로 접두사 압축을 사용합니다.

MongoDB는 WiredTiger를 통해 내부 캐시와 파일 시스템 캐시 모두를 활용합니다.

MongoDB 3.4부터는 기본 WiredTiger 내부 캐시 크기가 다음 중 큰 값으로 설정됩니다.

  • (RAM - 1GB)의 50%

  • 256 MB.

예를 들어 총 RAM이 4GB인 시스템에서 WiredTiger 캐시는 1 사용합니다.5GB RAM(0.5 * (4 GB - 1 GB) = 1.5 GB). 반대로 총 1 인 시스템에서는 25 GB RAM WiredTiger는 WiredTiger 캐시에 256 MB를 할당하는데, 이는 전체 RAM에서 1기가바이트를 뺀 값의 절반 이상이기 때문입니다(0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).

참고

컨테이너에서 실행할 때 등의 일부 인스턴스에서는 데이터베이스 메모리 제한이 총 시스템 메모리보다 낮을 수 있습니다. 이러한 인스턴스에서는 총 시스템 메모리가 아니라 이 메모리 제한이 사용 가능한 최대 RAM으로 사용됩니다.

메모리 제한을 보려면 hostInfo.system.memLimitMB 참조하세요.

기본적으로 WiredTiger는 모든 컬렉션에 Snappy 차단 압축을 사용하고 모든 인덱스에 접두사 압축을 사용합니다. 압축 기본값은 전역 수준에서 구성할 수 있으며 컬렉션 및 인덱스 생성 중에 컬렉션 및 인덱스별로 설정할 수도 있습니다.

WiredTiger 내부 캐시와 온디스크 형식의 데이터에는 서로 다른 표현이 사용됩니다.

  • 파일 시스템 캐시의 데이터는 온디스크 형식과 동일하며, 데이터 파일에 대한 모든 압축의 이점을 누릴 수 있습니다. 파일시스템 캐시는 운영 체제에서 디스크 I/O를 줄이기 위해 사용됩니다.

  • WiredTiger 내부 캐시에 로드된 인덱스는 온디스크 형식과는 다른 데이터 표현을 갖지만, 인덱스 접두사 압축을 활용하여 RAM 사용량을 줄일 수 있습니다. 인덱스 접두사 압축은 인덱싱된 필드에서 공통 접두사를 중복 제거합니다.

  • WiredTiger 내부 캐시의 컬렉션 데이터는 압축되지 않으며 온디스크 형식과 다른 표현을 사용합니다. 차단 압축은 상당한 온디스크 스토리지 절감을 제공할 수 있지만 서버에서 데이터를 조작하려면 압축을 풀어야 합니다.

MongoDB는 파일 시스템 캐시를 통해 자동으로 WiredTiger 캐시나 다른 프로세스에서 사용되지 않는 모든 여유 메모리를 사용합니다.

와이어드타이거 내부 캐시 크기를 조정하려면 storage.wiredTiger.engineConfig.cacheSizeGB--wiredTigerCacheSizeGB 참조하세요. WiredTiger 내부 캐시 크기를 기본값 이상으로 늘리지 마세요.

참고

storage.wiredTiger.engineConfig.cacheSizeGB는 WiredTiger 내부 캐시의 크기를 제한합니다. 운영 체제는 사용 가능한 여유 메모리를 파일 시스템 캐시에 사용하여 압축된 MongoDB 데이터 파일을 메모리에 유지할 수 있습니다. 또한 운영 체제는 사용 가능한 RAM을 사용하여 파일 시스템 차단과 파일 시스템 캐시를 버퍼링합니다.

추가적인 RAM 소비를 수용하려면 WiredTiger 내부 캐시 크기를 줄여야 할 수 있습니다.

기본 WiredTiger 내부 캐시 크기 값은 머신당 단일 mongod 인스턴스가 있다고 가정합니다. 단일 머신에 여러 MongoDB 인스턴스가 포함된 경우 다른 mongod 인스턴스를 수용할 수 있도록 설정을 줄여야 합니다.

시스템에서 사용 가능한 모든 RAM에 액세스할 수 없는 컨테이너에서 mongod를 실행하는 경우(예를 들어, lxc, cgroups, Docker 등) storage.wiredTiger.engineConfig.cacheSizeGB를 반드시 컨테이너에서 사용 가능한 RAM의 양보다 적은 값으로 설정해야 합니다. 정확한 양은 컨테이너에서 실행 중인 다른 프로세스에 따라 달라집니다. memLimitMB를 참조하세요.

캐시 및 퇴거율에 대한 통계를 보려면 serverStatus명령에서 반환된 wiredTiger.cache 필드를 참조하세요.

각 연결은 최대 1메가바이트의 RAM을 사용합니다.

연결 시 메모리 사용을 최적화하려면 다음을 확인하세요:

  • 배포에 대해 열려 있는 연결 수를 모니터링합니다. 열린 연결이 너무 많으면 RAM이 과도하게 사용되고 작업 세트에 사용할 수 있는 메모리가 줄어듭니다.

  • 더 이상 필요하지 않으면 연결 풀을 닫습니다. 연결 풀은 드라이버에서 유지 관리되며 즉시 사용할 수 있는 개방형 데이터베이스 연결의 캐시입니다. 불필요한 풀을 닫으면 추가 메모리 리소스를 사용할 수 있게 됩니다.

  • 연결 풀의 크기를 관리합니다. maxPoolSize 연결 문자열 옵션은 풀에 열려 있는 최대 연결 수를 지정합니다. 기본적으로 풀에는 최대 100개의 연결이 열려 있을 수 있습니다. maxPoolSize를 낮추면 연결에 사용되는 최대 RAM 양이 줄어듭니다.

    연결 풀을 구성하려면 연결 풀 구성 설정을 참조하세요.

체크포인트
버전 3.6부터는 MongoDB가 WiredTiger를 구성하여 체크포인트(즉, 스냅샷 데이터를 디스크에 기록하기)를 60초 간격으로 생성합니다. 이전 버전의 경우는 사용자 데이터에 대해 60초 간격으로 또는 2GB의 저널 데이터가 기록되면 둘 중 먼저 발생하는 시점에 WiredTiger에서 체크포인트가 발생하도록 설정합니다.
저널 데이터
WiredTiger는 다음 조건 중 하나라도 충족되면 버퍼링된 저널 레코드를 디스크에 동기화합니다:
  • 복제본 세트 멤버(프라이머리 및 세컨더리 멤버)의 경우:

    • 쓰기 작업에 j: true의 쓰기 고려를 포함하거나 암시하는 경우

    • 또한 세컨더리 노드의 경우 oplog 항목을 배치 적용할 때마다.

    참고

    writeConcernMajorityJournalDefault가 true인 경우 쓰기 고려 "majority"j: true를 의미합니다.

  • 100밀리초마다( storage.journal.commitIntervalMs 참조).

  • WiredTiger가 새 저널 파일을 만들 때. MongoDB는 100MB의 저널 파일 크기 제한을 사용하기 때문에 WiredTiger는 약 100MB의 데이터마다 새 저널 파일을 생성합니다.

WiredTiger 스토리지 엔진은 문서를 삭제할 때 데이터 파일의 빈 기록 목록을 유지합니다. 이 공간은 WiredTiger에서 재사용할 수 있지만, 매우 특별한 상황이 아닌 한 운영 체제로 반환되지 않습니다.

WiredTiger에서 재사용할 수 있는 빈 공간의 양은 wiredTiger.block-manager.file bytes available for reuse 제목 아래의 db.collection.stats() 출력에 반영됩니다.

WiredTiger 스토리지 엔진이 이 빈 공간을 운영 체제에 공개할 수 있도록 하려면 데이터 파일 조각 모음을 해제하면 됩니다. 이는 compact 명령을 사용하여 달성할 수 있습니다. 동작 및 기타 고려 사항에 대한 자세한 내용은 compact 을(를) 참조하세요.

데이터 크기를 포함한 컬렉션의 통계를 보려면 mongosh 내에서 db.collection.stats() 메서드를 사용합니다. 다음 예시에서는 orders 컬렉션에 대해 db.collection.stats()를 실행합니다.

db.orders.stats();

MongoDB는 컬렉션의 특정 크기를 반환하는 다음 메서드도 제공합니다.

다음 스크립트는 각 데이터베이스에 대한 통계를 출력합니다.

db.adminCommand("listDatabases").databases.forEach(function (d) {
mdb = db.getSiblingDB(d.name);
printjson(mdb.stats());
})

다음 스크립트는 각 데이터베이스의 각 컬렉션에 대한 통계를 인쇄합니다:

db.adminCommand("listDatabases").databases.forEach(function (d) {
mdb = db.getSiblingDB(d.name);
mdb.getCollectionNames().forEach(function(c) {
s = mdb[c].stats();
printjson(s);
})
})

각 인덱스에 할당된 데이터의 크기를 보려면 db.collection.stats() 메서드를 사용하여 반환된 문서에서 indexSizes 필드를 확인합니다.

인덱스가 접두사 압축(default for WiredTiger)을 사용하는 경우 해당 인덱스에 대해 반환된 크기는 압축된 크기를 반영합니다.

mongoshdb.stats()db.stats() 메서드는 '활성' 데이터베이스의 현재 상태를 반환합니다. 반환된 필드에 대한 설명은 dbStats 출력을 참조하세요.

← GridFS.
관리 →