MySQL 대 MongoDB 집계 성능

현재 일부 데이터베이스를 내 응용 프로그램에 테스트하고 있습니다. 주요 기능은 데이터 집계입니다 (이 사람과 유사 : Data aggregation mongodb vs mysql).MySQL 대 MongoDB 집계 성능

나는 동일한 문제에 직면하고있다. 샘플 테스트 데이터를 만들었습니다. MySQL 측에서는 조인하지 않으며, 하나의 innodb 테이블이다. 그것은 1,600 만 행의 데이터 세트입니다. 필터없이 전체 테이블에서 합계와 개수를 계산하므로 각각의 집계 엔진의 성능을 비교할 수 있습니다. 두 경우 모두 모든 데이터가 메모리에 저장됩니다. 두 경우 모두 쓰기로드가 없습니다.

MySQL (5.5.34-0ubuntu0.12.04.1)에서는 항상 2.03 및 2.10 초 정도의 결과를 얻고 있습니다. MongoDB (2.4.8, linux 64bits)에서 결과는 항상 4.1 ~ 4.3 초입니다.

인덱싱 된 필드에서 필터링을 수행하면 MySQL 결과 시간이 약 1.18 및 1.20으로 감소합니다 (처리 된 행 수가 데이터 세트의 절반으로 떨어집니다). MongoDB의 인덱싱 된 필드에서 동일한 필터링을 수행하면 결과 시간이 약 3.7 초로 감소합니다 (데이터 조건의 절반을 다시 처리합니다. 이는 일치 기준에 대한 설명으로 확인한 것입니다).

내 결론은 다음과 같습니다. 1) 내 문서가 매우 잘못 설계되었습니다. (실제로 가능할 수도 있음) 또는 2) MongoDB 집계 프레임 워크가 실제로 내 필요에 맞지 않습니다.

질문 : Mongo의 결과를 더 빨리 만들기 위해 (특수 mongoDB 구성, 문서 모델링 등) 무엇을 할 수 있습니까? 이것은 MongoDB가 적합하지 않은 경우입니까?

내 테이블 및 도큐멘트 스키마 :

| events_normal |

CREATE TABLE `events_normal` (
    `origem` varchar(35) DEFAULT NULL, 
    `destino` varchar(35) DEFAULT NULL, 
    `qtd` int(11) DEFAULT NULL, 
    KEY `idx_orides` (`origem`,`destino`) 
) ENGINE=InnoDB DEFAULT CHARSET=latin1 | 

{ 
    "_id" : ObjectId("52adc3b444ae460f2b84c272"), 
    "data" : { 
     "origem" : "GRU", 
     "destino" : "CGH", 
     "qtdResultados" : 10 
    } 
}

색인 및 필터링 된 필드는 "origem"및 "destino"입니다.

select sql_no_cache origem, destino, sum(qtd), count(1) from events_normal group by origem, destino; 
select sql_no_cache origem, destino, sum(qtd), count(1) from events_normal where origem="GRU" group by origem, destino; 

db.events.aggregate({$group: {   _id: {origem: "$data.origem", destino: "$data.destino"},   total: {$sum: "$data.qtdResultados" },   qtd: {$sum: 1}  } }) 
db.events.aggregate({$match: {"data.origem":"GRU" } } , {$group: {   _id: {origem: "$data.origem", destino: "$data.destino"},   total: {$sum: "$data.qtdResultados" },   qtd: {$sum: 1}  } })

고마워요!

출처

2013-12-15 Marcos Vinícius da Silva

집계 프레임 워크는 현재 낡은 (좋은 방법으로) 병렬 스레드 등으로 매우 성숙한 SQL만큼 빠르지는 않지만 다음 몇 가지 버전에서 많은 개선이 이루어져야합니다. 당신은 6이나 7 또는 4.01 초를 엄청나게 의미합니까? – Sammaye

@Sammaye 특정 beeing 미안 해요 : 약 4.1 초, 때로는 4.3입니다. 나는 그 문제를 바로 잡았다. –

집계는 실제로 MongoDB가 원래 설계된 것이 아니므로 실제로는 가장 빠른 기능이 아닙니다.

MongoDB를 실제로 사용하려면 Sharding을 사용하여 각 Shard에서 집계 공유를 처리 할 수 있습니다 (각 그룹이 하나의 클러스터에만있는 방식으로 Shard 키를 선택해야합니다. 반대를 달성 할 것이다). 그러나 이것은 MongoDB 클러스터가 더 많은 하드웨어를 사용하기 때문에 더 이상 MySQL과 공정한 비교가 될 수 없습니다.

출처

2013-12-15 16:41:57 Philipp

안녕하세요, Philipp, 답사 주셔서 감사합니다! 이 경우, MySQL 클러스터를 사용하여 MySQL 테이블을 분할 할 수 있으며 이론적으로 더 빠른 결과를 얻을 수 있습니까? –

@ MarcosViníciusdaSilva 어쩌면. MySQL 샤딩을 사용하지 않았습니다. MongoDB는 처음부터 샤딩을 위해 고안된 것이지만 MySQL은 샤딩을 추가 고려 사항으로 추가했기 때문에 MongoDB의 이익은 더 높다고 추측 할 수 있습니다. 그러나 이것은 경험이나 사실에 근거하지 않는 나의 추정 일뿐입니다. – Philipp

답변 해 주셔서 감사합니다. 모든 데이터베이스에서 결과를 빠르게 유지하기 위해보다 정교한 전략을 사용해야 할 것이라고 결론을지었습니다. –

MySQL 대 MongoDB 집계 성능

답변

관련 문제