mysql과 mongodb의 장점과 단점

관계형 데이터베이스와 비교하여 MongoDB의 장점은 다음과 같습니다.

①약한 일관성(최종 일관성)이 더 보장됩니다. 사용자 액세스 속도 :

예를 들어, 기존 관계형 데이터베이스에서 COUNT 유형 작업은 "현재" 상황에서 정확한 값을 얻을 수 있도록 데이터 세트를 잠급니다. 이는 ATM을 통해 계좌 정보를 확인할 때와 같은 경우에 중요하지만 Wordnik의 경우 데이터가 지속적으로 업데이트되고 증가하므로 이러한 "정확한" 보장은 거의 의미가 없지만 지연에 큰 영향을 미칩니다. 그들에게 필요한 것은 "대략적인" 숫자와 더 빠른 처리입니다.

하지만 어떤 경우에는 MongoDB가 데이터베이스를 잠글 수도 있습니다. 현재 수백 건의 요청이 있으면 요청이 쌓여 많은 문제가 발생할 수 있습니다. 잠금을 방지하기 위해 다음 최적화를 사용합니다.

각 업데이트 전에 먼저 레코드를 쿼리합니다. 쿼리 작업은 개체를 메모리에 저장하므로 업데이트가 최대한 빨라질 수 있습니다. 마스터/슬레이브 배포 시나리오에서 슬레이브 노드는 "-pretouch" 매개변수를 사용하여 실행될 수 있으며, 이 경우에도 동일한 효과를 얻을 수 있습니다.

여러 mongod 프로세스를 사용하십시오. 우리는 액세스 패턴에 따라 데이터베이스를 여러 프로세스로 분할합니다.

②문서구조의 저장방식으로 데이터 취득이 용이합니다.

계층적 데이터 구조의 경우 테이블과 같은 평면 구조를 사용하여 데이터를 저장하려는 경우 데이터를 쿼리하거나 가져오는 것이 매우 어렵습니다.

예 1:
"사전 항목"을 예로 들어 보겠습니다. 그다지 복잡하지는 않지만 "정의", "품사", "발음" 또는 "인용"과 같은 내용이 포함됩니다. 대부분의 엔지니어들은 관계형 데이터베이스에서 기본 키와 외래 키를 사용하여 이 모델을 표현하겠지만, "일련의 관련 테이블"보다는 "문서"로 생각하는 것이 더 낫지 않을까요? "dictionary.definition.partOfSpeech='noun'"을 사용하여 쿼리하는 것이 테이블 간의 일련의 복잡하고 비용이 많이 드는 조인 쿼리보다 더 편리하고 빠릅니다.

예 2:

관계형 데이터베이스에서는 블로그(기사 콘텐츠, 댓글, 댓글 투표 포함)가 여러 데이터 테이블 중간에 분산됩니다. MongoDB에서는 문서를 블로그를 표현하는 데 사용할 수 있으며 댓글과 투표는 문서 배열로 사용되어 기본 텍스트 문서에 배치됩니다. 이를 통해 데이터를 더 쉽게 관리할 수 있으며 기존 관계형 데이터베이스의 성능과 수평적 확장성에 영향을 미치는 "JOIN" 작업이 제거됩니다.

코드↓

> db.blogposts.save({ 제목: "My First Post", 작성자: {이름: "Jane", ID:1},
댓글 : [{ by: "Abe", text: "First" },
                    { by : "Ada", text : "좋은 게시물" }]
})

> db.blogposts.find( { "author.name" : "Jane" } )

> blogposts.findOne({ title : "My First Post", "author.name": "Jane",
댓글 : [{ by: "Abe", text: "First" },
                    { by : "Ada", text : "좋은 게시물" } ]
})
> db.blogposts.find( { "comments.by" : "Ada" } )

> db.blogposts.ensureIndex( { "comments.by" : 1 } ) ;

예시 3:
MongoDB는 현재 10gen에서 개발하고 유지 관리하는 문서 중심 데이터베이스로 기능이 풍부하고 완벽하며 MySQL을 완전히 대체할 수 있습니다. 제품 프로토타입을 위해 MongoDB를 사용하는 과정에서 우리는 MonogDB의 몇 가지 주요 특징을 요약했습니다:

익히고 이해하기 쉬운 JSON 스타일 구문 사용: MongoDB는 JSON의 변형인 BSON을 내부 저장소의 형식 및 구문으로 사용합니다. MongoDB의 모든 작업은 JSON 스타일 구문을 사용하며 클라이언트가 제출하거나 수신한 데이터는 JSON 형식으로 표시됩니다. SQL에 비해 더 직관적이고 이해하기 쉽고 마스터하기 쉽습니다.

스키마가 없고 내장된 하위 문서를 지원합니다. MongoDB는 스키마가 없는 문서 데이터베이스입니다. 데이터베이스는 여러 컬렉션을 가질 수 있으며 각 컬렉션은 문서 컬렉션입니다. 컬렉션 및 문서는 기존 데이터베이스의 테이블 및 행과 동일하지 않습니다. 컬렉션을 미리 정의할 필요가 없으며 언제든지 생성할 수 있습니다.

컬렉션에는 다양한 스키마를 가진 문서 레코드가 포함될 수 있습니다. 이는 이전 레코드의 문서에는 3개의 속성이 있고 다음 레코드의 문서에는 10개의 속성이 있을 수 있음을 의미합니다. 속성 유형은 기본 데이터 유형(예: 숫자, 문자열, 날짜 등)일 수 있습니다. 배열, 해시 또는 내장된 문서일 수도 있습니다. 이러한 방식으로 비정규화 데이터 모델을 달성하고 쿼리 속도를 향상시킬 수 있습니다.

③내장된 GridFS는 대용량 스토리지를 지원합니다.

GridFS는 대용량 데이터 저장을 지원할 수 있는 탁월한 분산 파일 시스템입니다.
대규모 데이터 세트의 빠른 범위 쿼리를 충족할 수 있는 GridFS 및 MongoDB가 내장되어 있습니다.

④내장 샤딩.

범위 기반 자동 샤딩 메커니즘을 제공합니다. 컬렉션은 레코드 범위에 따라 여러 세그먼트로 나눌 수 있으며 다른 샤드로 분할될 수 있습니다.

샤드는 복제와 결합될 수 있습니다. 샤딩 장애 조치는 복제본 세트를 통해 달성할 수 있으며, 서로 다른 샤드 간에 로드 밸런싱을 달성할 수 있습니다. 쿼리는 클라이언트에게 투명합니다. 클라이언트는 MongoDB에 의해 자동으로 백엔드 데이터 노드로 라우팅되는 쿼리, 통계, MapReduce 및 기타 작업을 수행합니다. 이를 통해 우리는 비즈니스에 집중하고 필요할 때 어려움 없이 업그레이드할 수 있습니다. MongoDB의 샤딩 설계 기능은 최대 약 20페타바이트까지 지원할 수 있으며 이는 일반 애플리케이션을 지원하기에 충분합니다.

이를 통해 MongoDB는 저렴한 PC 서버 클러스터에서 실행됩니다. PC 클러스터는 확장이 매우 편리하고 비용 효율적이므로 "샤딩" 작업의 복잡성과 비용을 피할 수 있습니다.

⑤ 풍부한 타사 지원. (이것은 MongoDB가 다른 NoSQL에 비해 갖는 장점이기도 합니다.)

인터넷에 있는 많은 NoSQL 오픈 소스 데이터베이스는 완전히 커뮤니티 기반이며 공식적인 지원이 없으므로 사용자에게 큰 위험을 안겨줍니다.

오픈 소스 문서 데이터베이스 MongoDB 뒤에는 상업용 교육 및 지원을 제공하는 상업용 회사인 10gen이 있습니다.

그리고 MongoDB 커뮤니티는 매우 활동적이며 많은 개발 프레임워크가 MongoDB에 대한 지원을 신속하게 제공했습니다. 많은 유명 대기업과 웹사이트도 프로덕션 환경에서 MongoDB를 사용하고 있습니다. 점점 더 많은 혁신적인 기업들이 Django 및 RoR에 어울리는 기술 솔루션으로 MongoDB를 선택하고 있습니다.

⑥뛰어난 성능:

수천만 개의 문서 객체와 거의 10G에 달하는 데이터가 있는 사용 사례에서 색인화된 ID에 대한 쿼리는 mysql보다 느리지 않지만 색인화되지 않은 필드에 대한 쿼리는 승리합니다. 실제로 MySQL은 대용량 데이터의 어떤 필드도 쿼리할 수 없는 데, mongodb의 쿼리 성능은 정말 놀랐습니다. 쓰기 성능도 매우 만족스럽습니다. 수백만 개의 데이터를 쓸 때 mongodb는 이전에 시도한 Couchdb보다 훨씬 빠릅니다. 기본적으로 10분 이내에 해결할 수 있습니다. 관찰 과정에서 mongodb는 CPU 킬러와는 거리가 멀다는 점을 덧붙이고 싶습니다.

관계형 데이터베이스와 비교했을 때 MongoDB의 단점:

①mongodb는 트랜잭션 작업을 지원하지 않습니다.

따라서 엄격한 거래 요건을 갖춘 시스템(예: 은행 시스템)에서는 절대 사용할 수 없습니다. (이 점은 장점 ①에 해당합니다)

②Mongodb는 공간을 너무 많이 차지합니다.

그 이유에 대해서는 공식 FAQ에서 다음과 같은 내용을 언급하고 있습니다.

1. 공간 사전 할당: 과도한 하드 디스크 조각화를 방지하기 위해 mongodb는 공간이 부족할 때마다 큰 하드 디스크 공간을 신청하며, 신청되는 양은 64M, 128M, 256M에서 256M까지 기하급수적으로 늘어납니다. 2G. 단일 파일의 최대 크기입니다. 데이터의 양이 증가함에 따라 블록 생성 용량이 증가하면서 데이터 디렉토리에서 이러한 파일을 볼 수 있습니다.

2. 필드 이름이 차지하는 공간: mongodb는 쿼리에 대한 각 레코드의 구조적 정보를 유지하기 위해 값 필드가 다음과 같은 경우 각 필드의 키-값을 저장해야 합니다. 키에 비해 도메인이 크지 않습니다. 예를 들어 숫자 데이터가 저장되면 데이터 오버헤드가 가장 커집니다. 공간 사용량을 줄이는 한 가지 방법은 필드 이름을 최대한 짧게 만들어 공간을 적게 차지하는 것입니다. 하지만 이렇게 하려면 가독성과 공간 사용량 간의 균형이 필요합니다. 필자는 작성자에게 필드 이름을 인덱스로 만들고 1바이트를 사용하여 각 필드 이름을 나타내도록 제안한 적이 있습니다. 그러면 필드 이름의 길이에 대해 걱정할 필요가 없습니다. 그러나 작성자의 우려는 무리가 없습니다. 이 인덱싱 방법은 각 쿼리 결과를 얻은 후 인덱스 값을 원래 값으로 대체한 다음 클라이언트로 전송해야 하기 때문에 시간이 많이 걸립니다. 현재 구현은 시간에 따른 공간 거래에 관한 것입니다.

3. 기록을 삭제해도 공간이 해제되지 않음: 기록 삭제 후 데이터의 대규모 이동을 방지하기 위해 원본 기록 공간은 삭제되지 않고 "삭제됨"으로 표시만 되어 있음을 이해하기 쉽습니다. , 나중에 반복해서 사용할 수 있습니다.

4. db.repairDatabase()를 정기적으로 실행하여 기록을 정리할 수 있지만 이 프로세스는 속도가 느립니다.

③MongoDB는 MySQL만큼 성숙한 유지 관리 도구를 갖추고 있지 않으며 이는 개발 및 IT 운영 측면에서 주목할 만합니다.

첨부파일 및 텍스트 업로드 제한으로 인해 일부 사진과 텍스트가 표시되지 않을 수 있습니다. 자세한 내용은 http://mp.weixin.qq.com/s?__biz=MzI5ODI3NzY2MA==&mid=100000725&idx를 참조하세요. =3&sn=1e1354fe3a774b01f3d4301f82735024# rd
모든 분들과의 소통을 환영합니다.
아래 QR코드를 스캔하시면 더 많은 아름다운 기사를 만나보실 수 있습니다! (예상치 못한 놀라움을 보려면 QR 코드를 스캔하세요!!)

구독번호 QR code.jpg (39.39 KB, 다운로드 수: 0)

첨부파일 다운로드

2016-6-2 18:37 업로드

WeChat 구독 계정(uniguytech100)과 서비스 계정(uniguytech)을 팔로우하여 더 많은 멋진 기사를 받아보세요!
[모두 기술 네트워크 토론 QQ 그룹], 그룹 번호: 256175955에 참여하실 수도 있습니다. 개인 소개를 적어주세요! 그것에 대해 함께 이야기합시다!