MongoDB 3.0은 오랫동안 기다려온 개선 사항이 포함된 주요 릴리스입니다. 가장 주목할 만한 점은 무엇일까요? 바로 옵션 스토리지 엔진인 WiredTiger입니다. WiredTiger는 버클리 DB를 개발한 사람들이 설립한 엔진입니다. 몽고DB는 WiredTiger의 쓰기 성능이 기본 스토리지 엔진인 MMAP보다 7~10배 빠르다고 주장합니다. 그럴 수도 있고 아닐 수도 있습니다. 어느 쪽이든 WiredTiger가 더 낫습니다.
그렇다면 몽고DB는 Couchbase Server와의 성능 격차를 좁혔나요?
아발론 컨설팅 벤치마킹 MongoDB와 Couchbase Server를 살펴보세요.
벤치마크 시나리오
벤치마크 시나리오는 강력한 일관성을 요구했으며, MongoDB와 Couchbase Server는 기본적으로 강력한 일관성을 보장하고, 다양한 사용 사례를 나타내고 읽기 및 쓰기 성능을 모두 반영하기 위해 50% 읽기 및 50% 업데이트의 균형 잡힌 워크로드, 메모리에 맞지 않는 작업 세트, 내구성과 가용성을 위해 복제될 데이터를 요구했습니다. 마지막으로 읽기 및 쓰기 지연 시간은 5ms를 초과할 수 없습니다.
Avalon 컨설팅은 두 데이터베이스를 모두 9개의 노드와 9개의 서버(서버당 하나의 노드)로 배포했습니다. 결국, 지원되는 프로덕션 환경에서 MongoDB 노드 수를 3배로 배포하려면 구독 수가 3배로 늘어나야 합니다.
- 강력한 일관성
- 50% 읽기, 50% 업데이트
- 읽기 및 쓰기 지연 시간 < 5ms
- 9개 서버, 9개 노드 - 노드당 1개 서버
- 복제된 데이터(기본 1개, 보조 2개)
- 데이터 > 메모리 *
- 3억 문서
- 286GB 기본(1x) + 572GB 보조(2x)
- 90GB 기본 메모리 상주(32%)
* 작업 세트는 전체 데이터 세트입니다.
방법론
오픈 소스 성능 테스트 프레임워크인 야후 클라우드 서버 벤치마크를 사용하여 Amazon Web Services에서 벤치마크를 수행합니다. 지연 시간이 5ms를 초과할 때까지 동시 클라이언트 수를 70개에서 525개로 35개씩 늘리면서 처리량과 95번째 백분위수 지연 시간을 측정합니다.
결과
- 72K에서 245개의 동시 클라이언트에서 MongoDB 지연 시간이 5ms를 초과했습니다.
- 카우치베이스 서버 처리량은 18만 6천 명에서 245명의 동시 클라이언트로 2.2배 더 높았습니다.
- 카우치베이스 서버 지연 시간은 298K에서 525개의 동시 클라이언트에서 5ms 미만이었습니다.
- 336K에서 805명의 동시 클라이언트로 Couchbase Server 지연 시간이 5ms를 초과했습니다.
결론
MongoDB의 문제는 스토리지 엔진이 아니라 샤딩이었는데, MMAP은 이를 개선하지 못했습니다. 지금도 마찬가지입니다. 샤딩의 한계를 극복할 수 있는 스토리지 엔진은 없습니다. MongoDB 지연 시간은 허용되지만 오래 가지 않습니다. WiredTiger는 지연 시간을 줄이는 데 도움이 되었지만, 동시성을 위해 설계되지 않은 데이터베이스 때문에 처리량이 여전히 제한적이었습니다. MongoDB가 선형적으로 확장된다고 가정했을 때, Couchbase Server만큼의 성능을 발휘하려면 3~5배의 노드 수가 필요했을 것입니다.
자세한 내용은 전체 문서에서 확인할 수 있습니다. 보고.
토론하기 해커 뉴스
