MongoDB에서 인덱스를 다시 작성해야 하는 이유와 시기는 무엇입니까?

MongoDB에서 인덱스를 다시 작성해야 하는 이유와 시기는 무엇입니까?

MongoDB와 한동안 같이 일하다가 오늘 동료와 상의하다가 의문이 생겼습니다.

MongoDB에서 인덱스를 만들면 수집이 처리되고 인덱스가 구축됩니다.

인덱스는 문서 삽입 및 삭제 시 업데이트되므로 인덱스를 삭제한 후 다시 작성하는 인덱스 재구성 작업을 실행할 필요가 없습니다.

MongoDB 문서에 따르면:

일반적으로 MongoDB는 정기 업데이트 중에 인덱스를 압축합니다.대부분의 사용자는 reIndex 명령이 필요하지 않습니다.그러나 컬렉션 크기가 크게 변경되었거나 인덱스가 디스크 공간을 과도하게 사용하는 경우에는 실행할 가치가 있을 수 있습니다.

가치 있는 인덱스 재구성 작업을 실행해야 하는 경우가 있습니까?

MongoDB 설명서에 따르면 일반적으로 인덱스를 정기적으로 재구성할 필요가 없습니다.

참고: 스토리지에 대한 모든 조언은 플러그형 스토리지 엔진 API를 도입한 MongoDB 3.0+를 통해 더욱 흥미로워집니다.아래의 제 의견은 특히 MongoDB 3.0 이전 버전의 기본 MMAP 스토리지 엔진과 관련된 것입니다.WiredTiger와 다른 스토리지 엔진은 데이터 및 인덱스에 대한 스토리지 구현 방식이 다릅니다.

다음과 같은 경우 MMAP 스토리지 엔진으로 인덱스를 재구축하면 몇 가지 이점이 있을 수 있습니다.

• 인덱스가 데이터에 비해 예상보다 많은 공간을 사용하고 있습니다.참고: 과거 데이터와 인덱스 크기를 모니터링하여 비교 기준을 설정해야 합니다.

• 이전 인덱스 형식에서 최신 인덱스 형식으로 마이그레이션하려고 합니다.재색인이 적합한 경우 업그레이드 노트에 이에 대해 설명합니다.예를 들어, MongoDB 2.0에서는 인덱스 성능이 크게 향상되었으므로 릴리스 노트에는 업그레이드 후 v2.0 형식에 대한 권장 재인덱스가 포함되어 있습니다.마찬가지로 MongoDB 2.6은 기본 동작이 다른 (기본적으로 희박함) 인덱스를 도입했습니다.기존 인덱스는 인덱스 버전 업그레이드 후 재구성되지 않으며, 업그레이드 여부/시기는 데이터베이스 관리자에게 맡겨집니다.

• 했습니다._id단조롭게 증가하는 키로 또는 키에서 수집하는 형식(예:개체 ID)를 임의 값으로 지정합니다. 버킷을 삽입할 b-tree 을 90 최적화가 _id항상 증가하는 s(참조: SERVER-983).만약 당신의 성격이_ids가 크게 변경되면 재인덱스를 사용하여 보다 효율적인 b-tree를 구축할 수 있습니다.

일반적인 B-트리 동작에 대한 자세한 내용은 위키백과: B-트리를 참조하십시오.

인덱스 사용 시각화

인덱스 내부를 좀 더 자세히 살펴보고 싶다면 몇 가지 실험 명령/도구를 사용해 볼 수 있습니다.MongoDB 2.4 및 2.6으로만 제한될 것으로 예상됩니다.

• indexStats
• storage-viz

MongoDB에서 제가 다른 시스템의 인덱싱에 대해 알고 있는 것과 귀하가 인용한 문서를 기반으로 이에 대해 몇 가지 가정을 할 수 있는 정확한 기술적 이유는 모르겠습니다.

지수의 일반적인 개념

한 문서에서 다른 문서로 이동할 때 전체 문서 모음에서는 처리할 필요가 없는 모든 데이터를 건너뛰는 데 많은 시간과 노력이 낭비됩니다.ID가 "1234"인 문서를 찾는 경우 각 문서의 100K+를 이동해야 하므로 속도가 느려집니다.

인덱스는 컬렉션에 있는 각 문서의 모든 내용을 검색할 필요 없이(디스크 읽기 헤드를 물리적으로 이동하는 등) 빠르게 이 작업을 수행합니다.기본적으로 키/값 쌍은 해당 문서의 ID와 위치를 제공합니다.MongoDB는 인덱스에 있는 모든 ID를 빠르게 스캔하여 필요한 문서의 위치를 찾고 직접 로드할 수 있습니다.

인덱스에 파일 크기 할당

인덱스는 기본적으로 훨씬 작은 위치에 저장된 키/값 쌍이기 때문에 디스크 공간을 차지합니다.컬렉션이 매우 많은 경우( 컬렉션에 있는 항목 수가 많은 경우) 인덱스의 크기가 커집니다.

대부분의 운영 체제는 특정 블록 크기의 디스크 공간 청크를 할당합니다.또한 대부분의 데이터베이스는 필요에 따라 디스크 공간을 큰 청크로 할당합니다.

10만 개의 문서가 추가될 때 10만 개의 파일 크기를 늘리는 대신, MongoDB는 아마도 1MB 또는 10MB 정도의 파일 크기를 증가시킬 것입니다. 실제 성장 크기가 얼마인지는 모르겠습니다.SQL Server에서 얼마나 빨리 성장하는지 알 수 있는데, MongoDB에는 아마도 그런 것이 있을 것입니다.

청크를 늘리면 데이터베이스를 지속적으로 확장할 필요가 없으므로 문서를 공간으로 더 빨리 '확장'할 수 있습니다.데이터베이스에 이미 10MB의 공간이 할당된 경우 해당 공간을 사용할 수 있습니다.각 문서에 대해 파일을 계속 확장할 필요는 없습니다.파일에 데이터를 쓰기만 하면 됩니다.

이는 디스크에 저장된 모든 컬렉션 및 컬렉션 인덱스에 해당됩니다.

파일 크기 및 인덱스 재구성

큰 컬렉션에 많은 문서가 추가 및 제거되면 색인은 조각화됩니다.인덱스를 작성해야 할 때 인덱스 파일의 중간에 공간이 있고 끝에 공간이 없기 때문에 인덱스 키가 순서대로 되어 있지 않을 수 있습니다.인덱스 키 사이에 공백이 많을 수도 있습니다.

인덱스에 10,000개의 항목이 있고 # 10,001을 삽입해야 할 경우 인덱스 파일 중간에 삽입할 수 있습니다.이제 지수는 모든 것을 다시 정리하기 위해 스스로를 재구성해야 합니다.여기에는 파일 끝에 공간을 만들고 항목 #10,001을 끝에 배치하기 위해 많은 데이터를 이동하는 작업이 포함됩니다.

인덱스를 지속적으로 스레싱(많은 항목을 제거하고 추가)하는 경우 인덱스 파일 크기를 늘린 후 항상 마지막에 항목을 넣는 것이 더 빠를 수 있습니다.인덱스를 만드는 속도는 빠르지만 파일에 오래된 항목이 삭제된 빈 구멍이 남아 있습니다.

인덱스 파일에 삭제된 항목이 있는 빈 공간이 있으면 인덱스를 읽을 때 작업이 낭비됩니다.인덱스 파일이 인덱스의 다음 항목으로 이동하기 위해 필요한 것보다 더 많은 이동량을 가집니다.지수 자체가 복구되는군요이는 매우 큰 컬렉션이나 컬렉션에 대한 매우 큰 변경사항에 시간이 걸릴 수 있습니다.

대용량 인덱스 파일 재구성

인덱스 파일을 적절한 크기로 압축하고 모든 것을 정리하려면 많은 디스크 액세스 및 I/O 작업이 필요합니다.항목을 장소를 벗어나 임시 위치로 이동하고, 적절한 위치에 공간을 확보한 후 다시 이동합니다.아, 그런데, 공간을 확보하기 위해서, 당신은 다른 물건들을 임시 위치로 옮겨야 했습니다.그것은 재귀적이고 강압적입니다.

따라서 컬렉션에 매우 많은 항목이 있고 해당 컬렉션에 정기적으로 항목이 추가 및 제거된 경우 인덱스를 처음부터 다시 작성해야 할 수 있습니다.이렇게 하면 현재 인덱스 파일을 지우고 처음부터 다시 작성할 수 있습니다. 이는 기존 파일 내부에서 수천 번의 이동을 시도하는 것보다 더 빠를 수 있습니다.물건을 옮기는 것이 아니라 처음부터 순차적으로 쓰는 것입니다.

수집 크기의 큰 변화

위에서 제가 생각하는 모든 것을 고려해 볼 때, 수집 규모의 큰 변화는 이런 종류의 타격을 야기할 것입니다.컬렉션에 10,000개의 문서가 있는데 그 중 8,000개를 삭제하면...이제 인덱스 파일에 8,000개의 항목이 있던 빈 공간이 있습니다.MongoDB는 물리적 파일의 나머지 2,000개 항목을 이동하여 압축된 형태로 재구축해야 합니다.

8,000개의 빈 공간이 정리되기를 기다리는 대신 나머지 2,000개의 항목으로 처음부터 다시 만드는 것이 더 빠를 수 있습니다.

결론?아마?

따라서 인용한 문서는 "빅 데이터" 요구사항이나 높은 스레싱 컬렉션 및 인덱스를 다룰 것입니다.

또한 인덱싱, 디스크 할당, 파일 조각화 등에 대해 알고 있는 지식을 바탕으로 추측하고 있습니다.

설명서의 "대부분의 사용자"는 99.9% 이상의 mongodb 컬렉션이 이에 대해 걱정할 필요가 없다는 것을 의미합니다.

MongoDB 특정 사례

MongoDB 문서에 따르면:

remove() 메서드는 인덱스를 제거하지 않습니다.

따라서 컬렉션에서 문서를 삭제하면 해당 컬렉션에 대한 색인을 다시 작성하지 않는 한 디스크 공간이 낭비됩니다.

언급URL : https://stackoverflow.com/questions/30345218/why-and-when-is-necessary-to-rebuild-indexes-in-mongodb