Mongodb와 MySQL의 비교 분석

이 기사의 내용은 Mongodb와 MySQL의 비교 분석에 관한 것입니다. 필요한 친구가 참고할 수 있기를 바랍니다.

데이터베이스에 저장된 데이터에는 테이블의 레코드를 고유하게 식별하는 데 사용되는 기본 키라는 특수 키 값이 있습니다. 즉, 테이블은 여러 기본 키를 가질 수 없으며 기본 키는 null일 수 없습니다. MongoDB이든 MySQL이든 기본 키에 대한 정의가 있습니다 .
MongoDB의 경우 기본 키는 "_id"라고 합니다. 데이터를 생성할 때 사용자가 기본 키를 적극적으로 할당하지 않으면 MongoDB는 자동으로 무작위로 할당된 값을 생성합니다.

MySQL에서는 MySQL이 데이터를 삽입할 때 PRIMARY KEY를 지정하여 기본 키 지정을 정의합니다. 기본 키가 지정되지 않은 경우 다른 도구인 인덱스는 기본 키의 기능을 대체하는 것과 동일합니다. 인덱스는 비어 있거나 중복을 가질 수 있습니다. 고유 인덱스라고 하는 중복을 허용하지 않는 또 다른 유형의 인덱스가 있습니다. 기본 키나 인덱스가 모두 지정되지 않으면 MySQL은 자동으로 데이터에 대한 키를 생성합니다.

스토리지 속도 비교

1. MongoDB는 _id 삽입을 지정하지 않습니다. > MySQL은 기본 키 삽입을 지정하지 않습니다. > MongoDB는 _id 삽입을 지정합니다.

2. MongoDB는 _id를 지정하지 않고 삽입할 때 속도 차이가 크지만 MySQL의 차이는 훨씬 작습니다.

분석:

1. _id 또는 기본 키를 지정하는 경우 두 데이터베이스는 삽입 시 인덱스 값을 처리하고 데이터베이스에 동일한 키 값이 있는지 확인해야 하므로 삽입 속도가 느려집니다.

2. MongoDB에서는 인덱스 삽입을 지정하는 것이 지정하지 않는 것보다 훨씬 느립니다. 이는 MongoDB의 각 데이터 조각에 대한 _id 값이 고유하기 때문입니다. _id를 지정하지 않고 데이터를 삽입하면 시스템에서 자동으로 _id를 계산하여 생성합니다. MongoDB는 컴퓨터 특성, 시간, 프로세스 ID 및 난수를 사용하여 생성된 _id가 고유한지 확인합니다. _id를 지정하여 삽입하는 경우 MongoDB는 데이터를 삽입할 때마다 이 _id가 사용 가능한지 확인해야 합니다. 데이터베이스에 데이터 항목이 너무 많으면 이 단계의 쿼리 오버헤드로 인해 전체 삽입 속도가 느려집니다. 데이터 베이스.

3. MongoDB는 시스템 메모리를 캐시로 완전히 사용하는데 이는 매우 뛰어난 기능입니다. 테스트 머신에는 64G의 메모리가 있습니다. 삽입 시 MongoDB는 메모리가 거의 데이터로 가득 찬 후에 하드 디스크에 데이터를 유지하기 위해 최선을 다합니다. 이는 _id를 지정하지 않고 삽입할 때 MongoDB가 훨씬 더 효율적인 이유이기도 합니다. 하지만 _id를 지정하여 삽입할 경우 데이터의 양이 메모리에 맞지 않을 경우 MongoDB는 중복 여부를 확인하기 위해 디스크에서 정보를 메모리로 읽어와야 하므로 삽입 효율이 느려집니다.

4. MySQL은 실제로 매우 안정적인 데이터베이스입니다. 기본 키를 지정하지 않고 삽입해도 효율성은 크게 다르지 않습니다.

삽입 안정성 분석

삽입 안정성이란 데이터의 양이 증가함에 따라 일정량의 데이터를 삽입했을 때의 삽입률을 말합니다.

이 테스트에서는 이 표시기의 눈금을 100,000으로 설정했습니다. 즉, 표시되는 데이터는 100,000개의 데이터가 삽입될 때 이 기간 동안 초당 몇 개의 데이터를 삽입할 수 있는지를 나타냅니다. ㅋㅋㅋ

4 . MySQL은 삽입을 위해 PRIMARY KEY를 지정하지 않습니다.

요약:

1. MongoDB는 _id 삽입>을 지정하지 않습니다. 기본 키> MySQL에서 기본 키를 지정하여 삽입> MongoDB에서 _id를 지정하여 삽입합니다.

2. 그림에서 볼 수 있듯이 기본 키를 지정하여 데이터를 삽입할 때 MySQL과 MongoDB의 데이터 크기가 서로 다를 경우 초당 삽입되는 데이터가 가끔씩 변동하게 되는데, 이는 정기적으로 표시됩니다. 버 현상. 데이터 삽입을 지정하지 않은 경우 대부분의 경우 삽입 속도는 비교적 평균적이지만, 데이터베이스의 데이터가 증가함에 따라 일정 시간이 지나면 삽입 효율이 일시적으로 떨어지다가 다시 안정됩니다.

3. 전반적으로 MongoDB의 속도 변동은 MySQL보다 심각하며 변동도 크게 나타납니다.

4. MongoDB에서 _id를 지정하여 삽입할 경우, 더 많은 데이터가 삽입되면 삽입 효율성이 크게 떨어집니다. 다른 세 가지 삽입 테스트에서는 삽입 속도가 처음부터 끝까지 대부분 표준으로 고정됩니다.

분석:

1. 글리치 현상은 너무 많은 데이터가 삽입되면 MongoDB가 메모리에 있는 데이터를 하드 디스크에 써야 하고 MySQL은 테이블을 다시 파티션해야 하기 때문입니다. 이러한 작업은 데이터베이스의 데이터가 특정 수준에 도달할 때마다 자동으로 수행되므로 가끔씩 명백한 결함이 발생합니다.

2. MongoDB는 결국 새로운 것이고, 그 안정성은 수년 동안 사용된 MySQL만큼 좋지 않습니다.

3. MongoDB가 지정된 _id를 삽입하면 성능이 크게 저하됩니다.

4. 읽는 데이터의 크기가 크지 않을 때 MongoDB의 쿼리 속도는 MySQL보다 훨씬 뒤떨어집니다.

5. 쿼리되는 데이터의 양이 점차 증가함에 따라 MySQL의 쿼리 속도는 꾸준히 감소하는 반면 MongoDB의 쿼리 속도는 다소 변동됩니다.

분석:

1. MySQL이 쿼리 최적화되지 않은 경우 쿼리 속도를 MongoDB와 비교해서는 안 됩니다. MongoDB는 시스템의 메모리 리소스를 최대한 활용할 수 있습니다. 우리의 테스트 머신에는 메모리가 클수록 MongoDB의 쿼리 속도는 더 빨라집니다. 결국 디스크와 메모리의 I/O 효율성은 동일하지 않습니다. .

2. 이번 실험에서도 쿼리 데이터는 무작위로 생성되기 때문에 쿼리할 데이터가 모두 MongoDB의 메모리 캐시에 저장될 확률은 매우 낮습니다. 쿼리할 때 MongoDB는 메모리 및 디스크의 데이터를 찾기 위해 여러 번 상호 작용해야 하므로 쿼리 속도는 상호 작용 횟수에 따라 달라집니다. 쿼리할 데이터의 양은 많지만 무작위로 생성된 이 데이터를 MongoDB가 디스크에서 가져오는 횟수는 더 적을 가능성이 있습니다. 따라서 평균 쿼리 속도가 더 빠릅니다. 이러한 관점에서 볼 때 MongoDB의 쿼리 속도 변동도 합리적인 범위 내에 있습니다.

3. MySQL의 안정성에는 의심의 여지가 없습니다.

결론

1. MySQL에 비해 MongoDB 데이터베이스는 읽기 작업이 많은 작업 모델에 더 적합합니다. MongoDB는 머신의 메모리 리소스를 최대한 활용할 수 있습니다. 머신에 풍부한 메모리 리소스가 있으면 MongoDB의 쿼리 효율성이 훨씬 빨라집니다.

2. "_id"로 데이터를 삽입할 경우 MongoDB의 삽입 효율성은 실제로 높지 않습니다. MongoDB 성능을 최대한 활용하려면 "_id" 없이 삽입한 후 해당 필드를 인덱싱하여 쿼리하는 것이 좋습니다.

3. MongoDB는 데이터베이스의 구체적인 데이터 형식이 불분명하거나 데이터베이스 데이터 형식이 자주 변경되는 수요 모델에 적합하며 개발자에게 매우 친숙합니다.

4. MongoDB는 공식적으로 서버 클러스터에 쉽게 배포할 수 있는 분산 파일 시스템과 함께 제공됩니다. MongoDB에는 서버 샤딩에 편리한 Shard라는 개념이 있습니다. 샤드가 추가될 때마다 MongoDB의 삽입 성능은 거의 두 배로 향상되고 디스크 용량도 쉽게 확장할 수 있습니다.

5. MongoDB에는 데이터 통계에도 매우 편리한 맵 축소 컴퓨팅 프레임워크가 지원됩니다.

MongoDB의 결함

1. 약한 트랜잭션 관계 지원. 이는 모든 NoSQL 데이터베이스의 일반적인 결함이기도 하지만 NoSQL은 트랜잭션 관계용으로 설계되지 않았으며 특정 애플리케이션에 대한 수요가 여전히 존재합니다.

2. 위 테스트에서 알 수 있듯이 안정성이 다소 부족합니다.

3. MongoDB는 개발자에게는 편리하지만, 운영 및 유지 관리 인력에 대한 수요가 상당히 높습니다. 업계에는 성숙한 MongoDB 운영 및 유지 관리 경험이 없으며 MongoDB의 데이터 저장 형식도 매우 무작위적입니다.

위 내용은 Mongodb와 MySQL의 비교 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!