MongoDB 디스크 공간 사용량 관리 및 절감을 위한 모범 사례

인기 있는 NoSQL 문서 데이터베이스인 MongoDB는 유연성과 확장성으로 유명합니다. 그러나 선제적인 관리 없이는 디스크 공간 사용량이 빠르게 증가하여 성능 저하, 시스템 중단, 인프라 비용 증가로 이어질 수 있습니다. MongoDB가 디스크 공간을 소비하는 방식을 이해하고 효과적인 관리 전략을 구현하는 것은 건강하고 효율적인 데이터베이스 환경을 유지하는 데 중요합니다.

이 문서는 MongoDB 디스크 공간을 관리하고 줄이기 위한 포괄적인 전략을 자세히 설명합니다. 컬렉션 압축, 대용량 인덱스 최적화 및 처리, 효율성을 위한 스토리지 엔진 설정 구성, 데이터 수명 주기 정책 구현과 같은 실용적인 기술을 탐구할 것입니다. 이러한 모범 사례를 따르면 불필요한 디스크 증가를 방지하고 안정적인 운영을 보장하며 MongoDB 배포의 수명을 연장할 수 있습니다.

MongoDB 디스크 공간 소비 이해하기

MongoDB는 여러 구성 요소에 디스크 공간을 사용합니다.

데이터 파일: 컬렉션 내의 실제 BSON 문서를 저장합니다.
인덱스 파일: 효율적인 쿼리 실행을 지원하기 위해 생성된 B-트리 인덱스를 저장합니다.
저널 파일 (WiredTiger): 데이터 내구성을 보장하기 위해 데이터 파일에 적용되기 전에 쓰기 작업을 기록합니다. 이는 미리 할당됩니다.
Oplog (운영 로그): 복제를 위해 필수적인 모든 쓰기 작업을 기록하는 복제본 세트의 특수 제한 컬렉션입니다.
진단 데이터: 로그, mongod 프로세스 파일 및 기타 시스템 관련 정보.

시간이 지남에 따라 업데이트, 삭제 및 문서 증가(패딩)로 인해 컬렉션과 인덱스가 조각화되거나 사용되지 않는 할당 공간을 포함하게 되어 비효율적인 디스크 사용으로 이어질 수 있습니다. 이 "공백"은 데이터베이스가 라이브 데이터에 더 이상 필요하지 않더라도 운영 체제가 즉시 회수하지 않습니다.

MongoDB 디스크 공간을 줄이는 전략

1. 컬렉션 및 인덱스 압축

압축 작업은 데이터 및 인덱스 파일을 더 효율적으로 다시 작성하여 사용되지 않는 디스크 공간을 회수하는 데 도움이 됩니다. 이는 특히 상당한 데이터 삭제 또는 업데이트 후에 유용할 수 있습니다.

컬렉션 압축

WiredTiger 스토리지 엔진(MongoDB 3.2 이후 기본값)의 경우 compact는 주로 삭제된 문서에서 여유 공간을 회수하고 컬렉션을 조각 모음합니다. MMAPv1의 compact 작업처럼 컬렉션의 데이터 파일을 처음부터 다시 빌드하지는 않습니다.

db.runCommand({ compact: "myCollection" })

compact 고려 사항:

compact 작업은 리소스 집약적일 수 있으며(CPU, I/O) 특히 대규모 컬렉션의 경우 상당한 시간이 걸릴 수 있습니다. 유지 보수 기간 동안 또는 복제본 세트의 보조 멤버에서 실행하는 것이 가장 좋습니다.
데이터를 새 위치에 다시 빌드한 다음 교체하기 때문에 압축하려는 컬렉션 크기와 동일한 여유 디스크 공간이 필요합니다.
샤딩된 클러스터의 경우 각 샤드에서 compact를 독립적으로 실행합니다.

인덱스 재구축

인덱스도 조각화될 수 있습니다. 인덱스를 재구축하면 공간을 확보하고 쿼리 성능을 향상시킬 수 있습니다.

db.myCollection.reIndex()

reIndex() 고려 사항:

reIndex()는 MongoDB 4.2 이후 온라인 작업입니다(새 인덱스에 충분한 디스크 공간 필요). 4.2 이전 버전에서는 데이터베이스(컬렉션뿐만 아니라)에 쓰기 잠금을 걸어 다른 모든 작업을 차단합니다. 먼저 보조 멤버에서 reIndex()를 실행한 다음 기본 노드를 전환하여 새 기본 노드에서 실행하는 것이 좋습니다.
compact와 유사하게 reIndex()는 작업 중에 추가 디스크 공간을 필요로 합니다.

`repairDatabase` (오프라인 작업)

심각한 조각화 또는 데이터 손상의 경우 repairDatabase는 모든 데이터 파일을 다시 빌드할 수 있습니다. 이는 오프라인 작업이며 mongod 인스턴스를 중지해야 합니다.

mongod --repair

경고: repairDatabase는 주의해서 처리하지 않으면 파괴적인 작업이 될 수 있고 시간이 매우 오래 걸릴 수 있으므로 공간 회수를 위한 최후의 수단으로 사용해야 합니다. 항상 백업을 준비하십시오.

2. 인덱스 최적화

인덱스는 성능에 중요하지만 상당한 디스크 공간을 소비할 수 있습니다. 사용되지 않거나 중복된 인덱스는 순수한 오버헤드입니다.

불필요한 인덱스 식별 및 삭제

정기적으로 인덱스를 검토하여 여전히 필요한지 확인하십시오.

컬렉션의 모든 인덱스 나열:
javascript db.myCollection.getIndexes()
인덱스 사용량 모니터링: 데이터베이스 프로파일링 활성화(db.setProfilingLevel(1)) 또는 db.collection.stats()를 사용하여 인덱스 활용도를 확인합니다. 클라우드 모니터링 도구는 종종 인덱스 사용량에 대한 통찰력을 제공합니다.
중복되거나 중복된 인덱스 식별: 예를 들어, { a: 1, b: 1 }에 대한 인덱스는 해당 복합 인덱스를 사용할 수 있는 쿼리의 경우 { a: 1 }에 대한 인덱스를 중복으로 만듭니다. { a: 1, b: 1 }에 대한 인덱스는 a와 b만 포함하는 쿼리의 경우 { a: 1, b: 1, c: 1 }에 대한 인덱스로도 포함됩니다.

확인되면 사용하지 않는 인덱스를 삭제합니다.

db.myCollection.dropIndex("indexName")

팁: 프로덕션에 적용하기 전에 항상 스테이징 환경에서 인덱스 삭제의 영향을 테스트하십시오.

부분 인덱스 사용

부분 인덱스는 지정된 필터 표현식을 만족하는 컬렉션의 문서만 인덱싱합니다. 이렇게 하면 인덱싱되는 문서 수가 줄어들어 디스크 공간을 절약하고 쓰기 성능을 향상시킵니다.

db.orders.createIndex(
   { customerId: 1, orderDate: -1 },
   { partialFilterExpression: { status: "active" } }
)

이 인덱스는 status가 "active"인 문서만 포함하므로 대부분의 주문이 "으로