복제 몽고를 사용하고 있으며, 컬렉션에는 약 1억 5천만 개의 레코드가 있으며, [크기=10GB, 저장 크기=3.4GB, 총 인덱스 크기: 6GB] 저장된 기록 레코드이므로 제거를 사용합니다. 30일 전(약 200만개) 기록을 삭제했는데, 인덱스 크기가 6GB에서 9GB로 늘어난 것을 확인했습니다.
일반적으로 삭제를 수행하는 데 특별한 작업이 필요하지 않습니다. MongoDB에서 사용하는 Btree도 자체 균형을 유지하므로 다시 빌드할 필요가 없습니다. btree의 균형에 영향을 미치는 3.0.7 및 이전 버전의 SERVER-21063 버그를 제외하고는 이에 대한 특별한 내용을 들어본 적이 없습니다. 주의가 필요합니다. 6G에서 9G로 늘어나는 이런 상황은 들어본 적이 없습니다. 슬레이브 노드에서도 마찬가지인지 확인할 수 있습니다. 가능하다면 확인을 위해 슬레이브 노드의 인덱스를 삭제하고 다시 생성하여 크기가 다른지 확인하십시오. 편집: 시도하기 전에 압축을 시도하여 작동하는지 확인할 수 있습니다. 인스턴스에 미치는 영향에 주의하세요. 보조 인스턴스를 분리하여 별도로 테스트하는 것이 가장 좋습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
일반적으로 삭제를 수행하는 데 특별한 작업이 필요하지 않습니다. MongoDB에서 사용하는 Btree도 자체 균형을 유지하므로 다시 빌드할 필요가 없습니다. btree의 균형에 영향을 미치는 3.0.7 및 이전 버전의 SERVER-21063 버그를 제외하고는 이에 대한 특별한 내용을 들어본 적이 없습니다. 주의가 필요합니다.
6G에서 9G로 늘어나는 이런 상황은 들어본 적이 없습니다. 슬레이브 노드에서도 마찬가지인지 확인할 수 있습니다. 가능하다면 확인을 위해 슬레이브 노드의 인덱스를 삭제하고 다시 생성하여 크기가 다른지 확인하십시오.
편집: 시도하기 전에 압축을 시도하여 작동하는지 확인할 수 있습니다. 인스턴스에 미치는 영향에 주의하세요. 보조 인스턴스를 분리하여 별도로 테스트하는 것이 가장 좋습니다.
문서에 이렇게 설명되어 있습니다. 데이터 삭제 시 컬렉션 전체를 삭제해도 인덱스는 삭제되지 않습니다. 그래서 이때는 인덱스를 재구축하는 것을 제안합니다.