몽고DB는 유나이티드 소프트웨어 어소시에이츠가 수행한 또 다른 벤치마크를 발표했습니다.
벤치마크는 다음을 평가하는 데 유용한 도구입니다. 데이터베이스 성능. 그러나 유용하려면 투명하고 반복 가능해야 합니다. 이러한 기준을 충족하지 못하면 결과가 의심스러울 수 있습니다.
최근 벤치마크에서 카우치베이스와 몽고DB는 서로 다른 두 가지 접근 방식을 취했습니다. Couchbase는 전체 구성을 명확하게 문서화했습니다. 그리고 는 모든 테스트 결과를 포함했습니다. MongoDB는 그렇지 않았습니다.
아래 표는 Avalon Consulting, LLC와 United Software Associates가 취한 다양한 접근 방식을 보여줍니다:
| 유나이티드 소프트웨어 어소시에이트 | 아발론 컨설팅, LLC | |
| YCSB | ||
| 참가 / 운영 | 400M/100M | 300M / 100M |
| 값 크기 | 누락 | 1K |
| 데이터 세트 크기 | 누락 | 286GB |
| 배포 요청 | 집피안 | 유니폼 |
| 데이터베이스 | ||
| 노드 | 누락 | MongoDB: 9 카우치베이스 서버: 9 |
| 복제본 | 누락 | 3(기본 1개, 보조 2개) |
| 복제 | 누락 | MongoDB: 비동기 카우치베이스 서버: 비동기 |
| 지속성 | 누락 | MongoDB: 비동기 카우치베이스 서버: 비동기 |
| 구성된 메모리(노드당) | 누락 | 몽고DB: 30GB 카우치베이스 서버: 30GB |
| 총 데이터 세트 크기(복제본 포함) | 누락 | 858GB |
| 메모리에 상주하는 기본 데이터 | 누락 | 32% |
| 버전 | ||
| 데이터베이스 | MongoDB: 3.0.3 카우치베이스 서버: 3.0.2 |
MongoDB: 3.0.0 카우치베이스 서버: 3.0.2 |
| 클라이언트 | MongoDB: 3.0.0 카우치베이스 서버: 2.1.2 |
MongoDB: 2.1.3 카우치베이스 서버: 2.1.0 |
| 하드웨어 | ||
| 서버 | 데이터베이스: 3 YCSB: 1 |
데이터베이스: 9x AWS EC2 i2.2xlarge YCSB: 2~23배 AWS EC2 r2.8x-large |
| 프로세서 | 둘 다: 3.0GHz 2배 | 데이터베이스: 8 vCPU(2.5GHz) YCSB: 32vCPU(2.5GHz) |
| 메모리 | 둘 다: 96GB | 데이터베이스: 61GB YCSB: 244GB |
| 스토리지 | 모두: 960GB SSD 2개 | 데이터베이스: 800GB SSD 2개 YCSB: 320GB SSD 2개 |
| 네트워킹 | 둘 다: 10GbE | 둘 다: 높음 |
| OS | 둘 다: 우분투 14.10 | 데이터베이스: CentOS 6 YCSB: Amazon Linux |
| OS | ||
| 투명한 거대한 페이지(THP) | 장애인 | 장애인 |
| NUMA | 장애인 | 장애인 |
향후 벤치마크를 위해 이 템플릿을 개선하는 데 MongoDB와 DataStax가 도움이 되길 바랍니다.
유나이티드 소프트웨어 어소시에이츠 벤치마크 결과
그들은 결과를 발표하지 않았습니다. 모두 테스트 결과를 발표했습니다.
벤치마크에서는 모든 데이터베이스의 이상적인 스레드 수를 워크로드에 따라 150개 또는 350개로 명시하고 있지만, 게시된 결과에 대한 스레드 수는 명시하지 않습니다.
워크로드 A 처리량
| 스레드 | MongoDB | 카우치베이스 서버 |
| 105 | 누락 | 누락 |
| 140 | 누락 | 누락 |
| 175 | 누락 | 누락 |
| 210 | 누락 | 누락 |
| 245 | 누락 | 누락 |
| 280 | 누락 | 누락 |
| 315 | 누락 | 누락 |
| 350 | 누락 | 누락 |
결과 - 워크로드 A 지연 시간
| 스레드 | MongoDB | 카우치베이스 서버 |
| 105 | 읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
| 140 | 읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
| 175 | 읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
| 210 | 읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
| 245 | 읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
| 280 | 읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
| 315 | 읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
| 350 | 읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
읽기: 읽기: 누락 쓰기: 쓰기: 누락 |
아발론 컨설팅, LLC 벤치마크 결과
그들은 다음과 같은 결과를 발표했습니다. 모두 테스트 그리고 에 스레드 수를 명시했습니다.
워크로드 A 처리량
| 스레드 | MongoDB | 카우치베이스 서버 |
| 105 | 61K | 110K |
| 140 | 65K | 141K |
| 175 | 67K | 154K |
| 210 | 70K | 170K |
| 245 | 74K | 193K |
| 280 | 최대 지연 시간 초과 | 238K |
| 315 | 최대 지연 시간 초과 | 245K |
| 350 | 최대 지연 시간 초과 | 252K |
결과 - 워크로드 A 지연 시간
| 스레드 | MongoDB | 카우치베이스 서버 |
| 105 | 읽기: 1.42ms 쓰기: 2.05ms |
읽기: .78ms 쓰기: .76ms |
| 140 | 읽기: 2.01ms 쓰기: 2.97ms |
읽기: .79ms 쓰기: .78ms |
| 175 | 읽기: 3.16ms 쓰기: 3.54ms |
읽기: .89ms 쓰기: .88ms |
| 210 | 읽기: 3.5ms 쓰기 4.49ms |
읽기: .93ms 쓰기: .92ms |
| 245 | 읽기: 4.19ms 쓰기 5.38ms |
읽기: .92ms 쓰기: .91ms |
| 280 | 최대 지연 시간 초과 | 읽기: .92ms 쓰기: .92ms |
| 315 | 최대 지연 시간 초과 | 읽기: 1.06ms 쓰기: .99ms |
| 350 | 최대 지연 시간 초과 | 읽기: 1.22ms 쓰기 1.22ms |
벤치마크 구성
벤치마크는 다음과 같은 질문에 답할 수 있어야 합니다:
- 하드웨어 구성은 어떻게 되나요?
- 운영 체제는 어떻게 구성되었나요?
- 데이터베이스 및 클라이언트 버전은 무엇인가요?
- 데이터베이스는 어떻게 구성되었나요?
- YCSB는 어떻게 구성되었나요?
그렇다면 이 유나이티드 소프트웨어 어소시에이츠 벤치마크에는 어떤 구성이 누락되어 있을까요?
- 노드 수
- 복제본 구성(#의 복제본
- 복제 구성(비동기 또는 동기화)
- 지속성 구성(비동기 또는 동기화)
- 값의 크기
- 데이터 세트의 크기
- 캐시 크기(노드당)
- 전체 데이터 세트의 크기(복제본 포함)
- 메모리에 상주하는 기본 데이터의 비율
- 모든 실행 결과
- 게시된 모든 실행의 스레드 수
또한 이 United Software Associates 백서에서 참조하는 GitHub 리포지토리에는 MongoDB, Cassandra 또는 Couchbase Server용 클라이언트 구성이 포함되어 있지 않습니다.
그렇다면 MongoDB 라우터와 구성 서버는 어떻게 되나요?
배포되었나요? 그렇다면 어디에 배포되었나요?
이 벤치마크에는 다음이 포함되어 있지 않으므로 잘 모르겠습니다. 모두 를 설정할 수 있습니다. 첫 번째 벤치마크 포함 대부분 의 구성에 대해 설명했지만, 여러 가지 실수. 이 벤치마크를 통해 실수를 수정했을 수 있지만 다음을 포함하지 못했습니다. 모두 를 설정합니다.
결론
벤치마크는 신뢰할 수 있는 것이 중요합니다. 누구나 벤치마크를 재현하고 그 결과를 검증할 수 있어야 합니다. 모든 구성이 제공되어야 하며, 가급적이면 클라우드 인프라에서 수행되어야 합니다. 그렇지 않으면 공급업체가 구성을 조작하여 불공정한 비교를 공정하게 보이게 할 수 있습니다.
이는 누구에게도 도움이 되지 않습니다.
리소스
몽고DB + 유나이티드 소프트웨어 어소시에이츠 벤치마크
백서 | 코드
카우치베이스 + 아발론 컨설팅, LLC 벤치마크
백서 | 코드
토론하기 해커 뉴스
