예, 이 답변은 독자를 오해할 수 있기 때문에 반대표를 던졌습니다. 어떤 종류의 데이터베이스라도 인덱스를 만드는 데는 엄청난 비용이 듭니다. 전체 테이블의 데이터를 순회해야 하기 때문에 큰 부담 없이 어떻게 가능할까요? 그렇기 때문에 이러한 상황을 적절하게 완화할 수 있는 {background: true} 옵션이 있습니다. 너무 많은 부담을 안고 있는 클러스터에서 인덱스를 생성할 경우, 온라인 시스템의 운영에 영향을 주지 않도록 노드를 하나씩 제거하여 인덱스를 생성한 후 온라인에 올려놓는 "롤링" 인덱스 생성 방법을 사용하는 것이 좋습니다. . 잠금 문제에 대해서는 WT 엔진 3.0부터 문서 잠금(행 잠금)을 지원합니다. 인덱스를 쿼리하는 데 드는 비용이 엄청납니다. 이는 아마도 인덱스가 제대로 설정되지 않았기 때문일 수 있습니다. 구체적인 예를 들어 논의해 보세요. 데이터가 1억개를 넘으면 함정이 많습니다. 구체적인 예를 들어 논의해 보세요.
개인적으로는 여전히 필요하다고 생각합니다. MongoDB에는 데이터베이스 잠금(낮은 버전)과 테이블 잠금(중형 버전)이 있더라도 파일을 저장할 샤드가 있어도 인덱스 생성 및 인덱스 쿼리에 따른 오버헤드가 발생합니다. 아직도 크다! ! ! ! 데이터가 1억 개가 넘으면 여전히 함정이 많습니다!
예, 이 답변은 독자를 오해할 수 있기 때문에 반대표를 던졌습니다.
어떤 종류의 데이터베이스라도 인덱스를 만드는 데는 엄청난 비용이 듭니다. 전체 테이블의 데이터를 순회해야 하기 때문에 큰 부담 없이 어떻게 가능할까요? 그렇기 때문에 이러한 상황을 적절하게 완화할 수 있는
{background: true}
옵션이 있습니다. 너무 많은 부담을 안고 있는 클러스터에서 인덱스를 생성할 경우, 온라인 시스템의 운영에 영향을 주지 않도록 노드를 하나씩 제거하여 인덱스를 생성한 후 온라인에 올려놓는 "롤링" 인덱스 생성 방법을 사용하는 것이 좋습니다. .잠금 문제에 대해서는 WT 엔진 3.0부터 문서 잠금(행 잠금)을 지원합니다.
인덱스를 쿼리하는 데 드는 비용이 엄청납니다. 이는 아마도 인덱스가 제대로 설정되지 않았기 때문일 수 있습니다. 구체적인 예를 들어 논의해 보세요.
데이터가 1억개를 넘으면 함정이 많습니다. 구체적인 예를 들어 논의해 보세요.
Mongodb는 수평으로 확장 가능한 데이터베이스 클러스터 시스템을 구축하고 각 샤딩 노드에 데이터베이스 테이블을 저장하는 데 사용할 수 있는 자동 샤딩 및 파티셔닝 아키텍처를 지원합니다.
데이터베이스 샤딩 대신 mongodb 샤딩을 참조하세요 [1]: https://yq.aliyun.com/article...
테이블을 월별로 나눌 수 있습니다. Name_03 Name_04 쿼리할 테이블의 이름은 프로그램의 타임스탬프에 따라 동적으로 변경됩니다.
개인적으로는 여전히 필요하다고 생각합니다. MongoDB에는 데이터베이스 잠금(낮은 버전)과 테이블 잠금(중형 버전)이 있더라도 파일을 저장할 샤드가 있어도 인덱스 생성 및 인덱스 쿼리에 따른 오버헤드가 발생합니다. 아직도 크다! ! ! ! 데이터가 1억 개가 넘으면 여전히 함정이 많습니다!