백미러를 통해 본 몽고DB와 데이터스택스

Thumbtack은 오늘 훌륭한 블로그 게시물을 발표했습니다(링크). 여기에는 Couchbase Server, MongoDB 및 DataStax Enterprise(Apache Cassandra)로 실행한 성능 테스트의 예비 결과가 나와 있습니다. 최종 결과는 벤치마크 보고서에 포함될 예정입니다. Thumbtack은 워크로드와 하드웨어에 따라 데이터베이스가 최적의 성능을 발휘하도록 구성하기 위해 Couchbase, MongoDB 및 DataStax와 협의했습니다. 결과는? 읽기 집약적인 워크로드와 균형 잡힌 워크로드 모두에서 Couchbase Server가 MongoDB 및 DataStax Enterprise보다 우수한 성능을 보였습니다.

성능은 데이터베이스의 기본 요구 사항입니다. 이는 사용자 경험과 고객 만족도에 직접적인 영향을 미칩니다. 고성능 데이터베이스는 많은 사용자가 동시에 지연 없이 데이터에 액세스할 수 있게 해줍니다. 비용에 직접적인 영향을 미칩니다. 고성능 데이터베이스는 더 적은 수의 노드를 필요로 합니다. 클라우드에 배포하면 더 적은 수의 인스턴스, 더 적은 수의 구독이 필요하며 요금도 절감됩니다. 데이터센터에 배포하는 경우 서버와 구독이 더 적게 필요하며 에너지 소비도 줄어듭니다(링크). 비용을 절감할 수 있습니다.

실행

• 성능 테스트는 YCSB로 실행되었습니다.
• 성능 테스트는 전용 서버에서 실행되었습니다.
• 성능 테스트는 4개의 서버에서 실행되었습니다.
• 성능 테스트는 두 가지 운영 워크로드로 실행되었습니다:
  • 읽기 집약적: 95% 읽기 / 5% 쓰기
  • 밸런스드: 50% 읽기 / 50% 쓰기
• 성능 테스트는 여러 클라이언트를 로드한 상태에서 실행되었습니다.

데이터

• 가치: 20M
• 값 크기: 150바이트
• 복제본: 2
• 90% 인메모리

읽기 집중

MongoDB의 6.5배 처리량을 자랑하는 Couchbase Server.
데이터스택 엔터프라이즈의 7.5배 처리량을 자랑하는 Couchbase Server.

읽기 지연 시간이 Couchbase Server의 2배인 MongoDB.
데이터스택스 엔터프라이즈, 읽기 지연 시간이 카우치베이스 서버의 3.1배입니다.

* 지연 시간은 밀리초 단위로 측정됩니다.
** MongoDB의 워크로드가 96개의 클라이언트 스레드에서 64개의 클라이언트 스레드로 감소하여 지연 시간을 줄였습니다.

이는 놀라운 일이 아닙니다.

첫째, 카우치베이스 서버는 최고의 읽기 성능을 제공하기 위해 통합 인메모리 캐시를 제공합니다(링크). 성능을 위해 설계되었기 때문에 메모리에 있는 데이터에 효율적으로 액세스해야 합니다.

둘째, Couchbase Server는 스마트 클라이언트를 활용합니다. Couchbase Server 클라이언트는 한 번의 요청(클라이언트에서 노드로)이 필요한 반면, MongoDB 및 DataStax Enterprise 클라이언트는 두 번의 요청(클라이언트에서 노드로, 노드에서 노드로)이 필요합니다. Couchbase Server 클라이언트는 데이터가 저장된 노드를 결정하고 직접 읽기 요청을 보냅니다. 그러나 MongoDB 클라이언트는 읽기 요청을 라우터로 보냅니다. 라우터는 데이터가 저장된 노드를 결정하고 읽기 요청을 라우터에 전달합니다(링크). DataStax Enterprise 클라이언트는 임의의 노드로 읽기 요청을 보냅니다. 임의 노드는 데이터가 저장된 노드를 결정하고 읽기 요청을 전달합니다(링크).

한 번의 요청이 두 번의 요청보다 빠릅니다.

균형 잡힌

MongoDB보다 7.6배 높은 처리량을 자랑하는 Couchbase Server.
데이터스택 엔터프라이즈보다 처리량이 2.7배 많은 카우치베이스 서버.

MongoDB, 쓰기 지연 시간이 Couchbase Server의 3배입니다.

* 지연 시간은 밀리초 단위로 측정됩니다.
** MongoDB의 워크로드가 96개의 클라이언트 스레드에서 64개의 클라이언트 스레드로 감소하여 지연 시간을 줄였습니다.

이는 놀라운 일이 아닙니다.

최고의 쓰기 성능을 제공하기 위해 Couchbase Server는 먼저 통합된 인메모리 캐시에 씁니다. 그런 다음 내구성을 위해 캐시를 저장 장치와 동기화합니다(링크).

읽기 작업과 마찬가지로, MongoDB 및 DataStax Enterprise는 쓰기 작업에도 두 번의 요청이 필요합니다. Couchbase Server는 그렇지 않습니다.

Couchbase Server는 배포 내의 모든 노드에 대한 쓰기를 스케일아웃하는 반면, MongoDB는 기본 노드에 대한 쓰기를 제한합니다(링크). 그 결과, 4개의 Couchbase Server 노드 모두 쓰기 작업을 실행했습니다. 그러나 MongoDB 노드는 두 개만 쓰기 작업을 실행했습니다. 나머지 두 노드는 보조 노드였습니다.

카우치베이스 서버는 문서 수준 잠금을 구현합니다. 이를 통해 Couchbase Server 노드는 한 번에 많은 쓰기를 실행할 수 있습니다. 그러나 MongoDB는 데이터베이스당 단일 잠금을 구현합니다(링크). 몽고DB 노드는 데이터베이스당 한 번에 한 번만 쓰기를 실행하도록 제한됩니다.

DataStax Enterprise는 쓰기 집약적인 워크로드에서 쓰기 요청을 짧은 레이턴시로 유지했습니다. 그러나 읽기 요청에 대해서는 그렇게 할 수 없었습니다. 결과적으로 읽기 지연 시간이 늘어나면서 처리량이 감소했습니다.

참고

강력한 일관성을 위해 구성되었음에도 불구하고 Couchbase Server의 처리량은 MongoDB 및 DataStax Enterprise보다 2~7배 더 많았습니다.

MongoDB는 최종적인 일관성을 위해 구성되었습니다.

결과적으로 몽고DB는 두 기본 노드에서 읽기 작업을 실행합니다. 그리고 보조 노드를 추가하여 성능을 향상시킵니다. 읽기 작업을 확장합니다. 그러나 읽기 작업이 일관되지 않은 데이터를 반환하도록 허용하여 일관성을 희생합니다. 기본 구성에서는 일관성을 유지하기 위해 기본 노드에서 읽기 작업을 실행합니다(링크). 그러나 성능이 저하됩니다.

DataStax Enterprise는 궁극적인 일관성을 위해 구성되었습니다.

결과적으로 DataStax Enterprise는 단일 노드에서 읽기 및 쓰기 작업을 실행하여 성능을 향상시킵니다. 그러나 읽기 작업이 일관되지 않은 데이터를 반환하도록 허용하여 일관성을 희생합니다. 강력한 일관성을 위해 구성한 경우 DataStax Enterprise는 일관성을 유지하기 위해 여러 노드(즉, 쿼럼)에서 읽기 및 쓰기 작업을 실행합니다(링크). 그러나 성능이 저하됩니다.

처리량, 지연 시간 및 동시성

Thumbtack은 Couchbase Server가 경쟁 제품보다 성능이 뛰어날 것으로 예상했습니다. 확장성과 성능을 위해 설계되었으며 이러한 엔지니어링이 아키텍처에 반영되어 있습니다. 높은 처리량, 짧은 지연 시간 및 동시성을 위해 설계되었습니다.

카우치베이스 서버의 처리량은 가벼운 워크로드에서 몽고DB 및 DataStax Enterprise의 약 2배에 달합니다. 그 이유는 지연 시간이 다른 제품의 절반 정도이기 때문입니다. 단일 실런트 스레드로 성능 테스트를 수행했다면 지연 시간이 처리량을 결정했을 것입니다. 그러나 동시성이 결정적인 요소입니다. 카우치베이스 서버는 아직 포화 상태가 아닙니다. 워크로드가 증가하면 처리량이 증가했습니다. MongoDB와 DataStax Enterprise는 가벼운 워크로드에서는 어느 정도 포화 상태입니다. 워크로드가 증가하면 지연 시간이 증가했습니다.

* x-asix는 YCSB 클라이언트 스레드의 총 개수입니다.

요약

Couchbase Server는 최고의 성능을 제공할 뿐만 아니라 확장도 쉽습니다(링크) 및 일관성(링크).

벤치마크에 대한 전체 설명과 예비 결과가 포함된 PDF를 확인할 수 있습니다.

보고서 전문은 다음과 같습니다. 사용 가능.