NoSQL 벤치마크 분석하기

2014년 가을 NoSQL 벤치마크를 분석해 보겠습니다.

아파치 카산드라 / 데이터스택스 엔터프라이즈. 몽고DB. 카우치베이스 서버.

Go.

하드웨어

네트워크: 96Gb/s(1Gb/s 스위치, 48포트)

잠깐, 96Gb/s? 전이중 매트릭스입니다. (링크)

수십 대의 서버로 벤치마킹해보는 건 어떨까요?

저는 베어메탈 서버, 온프레미스 서버에서 수행한 벤치마크를 선호합니다. 비용이 저렴하지 않습니다.

데이터

테라바이트급 데이터로 벤치마킹해 보시겠습니까?

목표는 메모리에 작업 세트가 있을 때 데이터베이스가 얼마나 잘 작동하고 확장되는지 파악하는 것입니다. 작업 세트는 32GB가 될 수도 있고 384GB가 될 수도 있습니다. 상관없었을 것입니다. 메모리에 딱 맞았으니까요. 작업 세트는 101TB의 데이터일 수도 있고, 901TB의 데이터일 수도 있습니다. 상관없었을 것입니다. 메모리에 딱 맞았으니까요.

넷플릭스에서 영화를 스트리밍하는 고객을 생각해 보세요. 수많은 고객이 있습니다. 하지만 특정 시점에 영화를 스트리밍하는 고객은 극히 일부에 불과합니다. 이것이 문제입니다. 웹 및 모바일 애플리케이션 사용자를 생각해 보세요. 저는 아내와 함께 Words with Friends를 플레이합니다. 한 번에 두세 개의 게임을 플레이합니다. 가끔씩 앱을 실행합니다. 몇 분은 아니더라도 몇 분 정도는 아내를 이길 수 있는 적절한 단어를 골라 플레이합니다. 저희는 아마존 프라임에 열광합니다. 하지만 쇼핑은 가끔씩만 하죠. 쇼핑을 할 때면 우리는 일하고 있습니다. 현재 쇼핑 중인 고객. 모든 고객은 아닙니다. 그리고 실시간 데이터가 있습니다. 클릭 스트림 분석과 센서 데이터를 생각해 보세요. 작업 집합은 현재 웹사이트를 방문 중인 사용자입니다. 모든 사용자가 아닙니다. 작업 집합은 센서 데이터의 마지막 분, 마지막 시간 또는 마지막 날입니다. 모든 센서 데이터가 아닙니다.

인메모리 작업 세트는 읽기 성능을 향상시키지만 쓰기 성능은 향상시키지 않습니다.

모든 데이터는 영구적이었습니다.

구성

일관성

아파치 카산드라, 결국 일관성(하나). MongoDB 및 Couchbase Server, 일관성.

내구성 / 지속성

Apache Cassandra 및 몽고DB와 Couchbase Server, 비동기 지속성.

참고: 아파치 카산드라에서는 커밋 로그가 비활성화되었습니다.

복제

두 개의 사본이 있습니다.

토폴로지

아파치 카산드라 및 카우치베이스 서버, 서버당 하나의 노드. MongoDB, 서버당 두 개의 노드.

참고: MongoDB는 마스터/슬레이브 토폴로지에 의존합니다. 모든 서버가 클라이언트의 읽기/쓰기 요청에 응답하도록 하기 위해 모든 서버에 마스터와 슬레이브(서로 다른 샤드에서)가 하나씩 설치되어 있습니다.

워크로드

읽기 헤비: 95% 읽기 / 5% 쓰기
밸런스드: 50% 읽기/50% 쓰기

데이터베이스 노드 및 클라이언트 스레드

벤치마크는 4개, 6개, 8개의 서버를 배포하여 수행했습니다.

벤치마크는 클라이언트 스레드 수를 늘리면서 수행했습니다.

결과

무거운 읽기

아파치 카산드라

처리량은 248~496개의 클라이언트 스레드 사이에서 최고치를 기록합니다: 99K 작업/초.
노드를 추가하면 처리량이 증가합니다.

지연 시간은 1ms 미만입니다.
노드를 추가하면 지연 시간이 줄어듭니다.

MongoDB

처리량은 132~198개의 클라이언트 스레드 사이에서 최고치를 기록합니다: 227K 작업/초.
노드를 추가하면 처리량이 증가합니다.

지연 시간은 최대 231개 클라이언트 스레드까지 1ms 미만입니다: 200K 작업/초.
노드를 추가하면 지연 시간이 줄어듭니다.

카우치베이스 서버

처리량은 2,970개의 클라이언트 스레드에서 최고치를 기록합니다: 162만 작업/초.
노드를 추가하면 처리량이 증가합니다.

지연 시간은 최대 1,320개 클라이언트 스레드까지 1ms 미만입니다: 144만 작업/초.
노드를 추가하면 지연 시간이 줄어듭니다.

몽고DB 대 카우치베이스 서버

동일한 부하에서 MongoDB와 Couchbase 서버의 처리량과 지연 시간을 비교해 보겠습니다.

Couchbase Server 처리량은 부하가 증가하면 증가합니다. 몽고DB는 그렇지 않습니다.

카우치베이스 서버 지연 시간은 최대 264개 클라이언트 스레드까지 0.6ms 미만입니다: 642K 작업/초.
MongoDB는 최대 231개 클라이언트 스레드까지 1ms 미만입니다: 200K 작업/초

설명

• 몽고DB 읽기 지연 시간은 메모리 매핑된 파일의 이점이 있습니다. 그러나 메모리 매핑된 파일은 직접 메모리만큼 성능이 좋지 않습니다. 게다가 MongoDB는 구식의 복잡한 토폴로지에 의존합니다. 실제로 이 벤치마크에서는 16개의 노드가 있는 MongoDB와 8개의 노드가 있는 Couchbase Server를 비교했습니다.

아파치 카산드라 v 카우치베이스 서버

카우치베이스 서버 처리량은 부하가 증가하면 증가합니다. 아파치 카산드라는 그렇지 않습니다.

카우치베이스 서버 지연 시간은 최대 792개 클라이언트 스레드까지 0.7ms 미만입니다: 1.22M 작업/초.
아파치 카산드라 지연 시간은 1ms 이상입니다.

설명

아파치 카산드라는 기본적으로 비활성화되어 있는 열악한 행 캐시(JIRA).

균형 잡힌 읽기/쓰기

아파치 카산드라

처리량은 272~544개의 클라이언트 스레드 사이에서 최고치를 기록합니다: 89K 작업/초.
노드를 추가하면 처리량이 증가합니다.

지연 시간은 최대 680개 클라이언트 스레드까지 1ms 미만입니다: 79K 작업/초.
노드를 추가하면 지연 시간이 줄어듭니다.

MongoDB

처리량은 256개 클라이언트 스레드에서 최고치를 기록합니다: 85K 작업/초.
노드를 추가하면 처리량이 증가합니다.

지연 시간은 1ms 미만입니다.
노드를 추가하면 지연 시간이 줄어듭니다.

카우치베이스 서버

처리량은 3,000개의 클라이언트 스레드에서 최고치를 기록합니다: 118만 작업/초.
노드를 추가하면 처리량이 증가합니다.

지연 시간은 최대 480개 클라이언트 스레드까지 1ms 미만입니다: 499K 작업/초.
노드를 추가하면 지연 시간이 줄어듭니다.

몽고DB 대 카우치베이스 서버

동일한 부하에서 MongoDB와 Couchbase Server의 처리량과 지연 시간을 비교해 보겠습니다.

Couchbase Server 처리량은 부하가 증가하면 증가합니다. 몽고DB는 그렇지 않습니다.

카우치베이스 서버 지연 시간은 최대 360개 클라이언트 스레드까지 0.8ms 미만입니다: 457K 작업/초.
MongoDB 지연 시간은 1ms 이상입니다.

설명

한 번 잠그는 것만으로는 도움이 되지 않습니다(매뉴얼 | JIRA). 문서 수준 잠금은 2010년부터 요청되었습니다.

아파치 카산드라 v 카우치베이스 서버

카우치베이스 서버 처리량은 부하가 증가하면 증가합니다. 아파치 카산드라는 그렇지 않습니다.

카우치베이스 서버 지연 시간은 최대 480개 클라이언트 스레드까지 1ms 미만입니다: 499K 작업/초.
Apache Cassandra 지연 시간은 최대 680개 클라이언트 스레드까지 1ms 미만입니다: 79K 작업/초.

설명

아파치 카산드라는 멤테이블의 쓰기 지연 시간 이점이 있지만, 카우치바스 서버는 동시성을 위해 설계되었습니다.

결론

질문이 있으신가요?

다음에서 댓글을 달거나 토론에 참여하세요. Reddit 또는 HN.

백서를 다운로드할 수 있습니다. 여기.