몽고DB는 독립적인 벤치마크 단일 노드 배포에서 몽고DB, 아파치 카산드라, 카우치베이스 서버의 성능을 비교하여 다음과 같이 대응합니다. 하나 에서 9노드 배포에서 MongoDB와 Couchbase Server의 성능을 비교한 결과를 발표했습니다. 1) 단일 노드로 제한되고, 2) 많은 데이터를 저장하지 않으며, 3) 많은 사용자를 지원하지 않을 때 MongoDB의 성능이 우수합니다. 이것이 바로 MongoDB의 최적 조건입니다.

MongoDB는 개발자가 개념 증명 또는 소규모 애플리케이션을 쉽게 구축할 수 있게 함으로써 NoSQL 데이터베이스에 대한 인지도를 높였습니다. 그러나 MongoDB는 프로덕션 배포의 엄격한 요구 사항을 충족할 수 없습니다. 반면에 Couchbase Server는 분산 데이터베이스로 배포할 때 그 진가를 발휘합니다. 더 많은 데이터를 저장하고, 더 많은 사용자를 지원하고, 더 높은 처리량과 더 짧은 지연 시간으로 데이터에 액세스할 수 있도록 쉽게 확장할 수 있습니다.

1) 단일 노드 벤치마크는 확장성 요구 사항을 해결하지 못함

소규모 데이터 세트와 소수의 사용자로 데이터베이스의 성능을 확인하려면 단일 노드 배포로 벤치마킹하세요. 대규모 데이터 세트와 많은 사용자가 있는 프로덕션 환경에서 데이터베이스의 성능을 확인하려면 클러스터된 배포로 벤치마킹하세요.

규모에 따른 성능을 측정하는 것뿐만 아니라 기업 요구 사항을 충족하면서 성능을 측정하는 것도 중요합니다. 예를 들어, 고가용성.

분산 배포의 성능을 비교하지 않은 이유는 무엇인가요? MongoDB는 단일 노드 이상으로 확장하기가 어렵습니다.

인포메이션위크(링크), 확장은 선형적이지 않습니다. 모든 쓰기는 여전히 단일 노드인 기본 노드에서 실행되기 때문에 MongoDB 복제본 세트에 노드를 추가해도 쓰기 성능이 향상되지는 않습니다. 모든 쓰기는 여전히 기본 노드에서 실행되므로 MongoDB 샤드도 마찬가지입니다. 샤드당 노드가 3개인 샤드가 3개 있는 경우, 쓰기는 3개의 기본 노드에서 실행됩니다.

2) 벤치마크는 카우치베이스 서버에 대해 다른 쓰기 시나리오를 적용했습니다 - 사과 대 사과 비교가 아닙니다.

MongoDB는 쓰기당 하나의 작업, 즉 업데이트를 수행했습니다. 그러나 MongoDB는 실수로 CouchBase Server가 쓰기당 읽기, 업데이트의 두 가지 작업을 수행하도록 했습니다. 이로 인해 Couchbase Server의 쓰기 성능이 제한되었습니다.

MongoDB(WiredTiger 포함) 및 Couchbase Server는 문서 수준 잠금을 활용합니다. 두 클라이언트가 동시에 동일한 문서를 업데이트하면 그 중 하나가 실패하고 업데이트를 다시 시도해야 합니다. 이것은 MongoDB와 Couchbase Server 모두에 해당되는 경우입니다. 이 벤치마크에서는 MongoDB에 대한 쓰기 시나리오였지만, Couchbase Server는 그렇지 않았습니다.

또 다른 쓰기 시나리오는 다른 클라이언트가 먼저 문서를 업데이트한 경우 클라이언트가 문서를 업데이트할 수 없도록 해야 하는 경우입니다. 이 쓰기 시나리오에서 Couchbase Server는 비교 및 스왑을 지원하는 반면, MongoDB는 "현재 문서가 있으면 업데이트" 방식을 권장합니다. 패턴. 이것은 Couchbase Server의 쓰기 시나리오였지, MongoDB의 쓰기 시나리오는 아니었습니다.

왜 몽고DB는 CouchBase Server가 비교 및 스왑을 수행하도록 하면서 자체적인 "현재 문서 업데이트" 패턴을 구현하지 않나요?

3) 벤치마크는 현재 클라이언트가 아닌 구형 카우치베이스 클라이언트를 활용했습니다.

MongoDB는 2013년에 출시된 오래된 클라이언트 라이브러리를 Couchbase Server에 사용하기로 결정했고, 이로 인해 Couchbase Server의 성능이 제한되었습니다. 작년 9월에 Netty와 RxJava를 기반으로 하는 새로운 클라이언트 라이브러리를 출시했고, 2월과 3월에 마이너 릴리스를 출시했습니다.

왜 몽고DB는 오래된 클라이언트 라이브러리로 Couchbase Server를 벤치마킹하면서 최신 클라이언트 라이브러리로 스스로를 벤치마킹할까요?

4) 단일 노드 내구성과 분산 데이터베이스 내구성 비교

내구성의 핵심은 서버에 장애가 발생했을 때 데이터가 손실되지 않도록 하는 것입니다. 이 벤치마크에서는 단일 노드 배포로 수행되었기 때문에 데이터가 디스크에 기록될 때만 내구성을 유지할 수 있습니다. 이는 기존 관계형 데이터베이스의 한계와 동일합니다.

오늘날 분산 데이터베이스는 데이터 손실 위험을 분산하는 최신 접근 방식을 통해 여러 노드에 데이터를 복제하여 내구성을 높입니다. 카우치베이스 서버는 기존 데이터베이스처럼 디스크에 쓰면서도 노드 간에 더 빠른 메모리 간 복제를 활용한다는 점에서 독특합니다. 데이터는 내구성이 뛰어날 뿐만 아니라 가용성도 높습니다. 다른 서버, 다른 랙 또는 다른 데이터센터의 노드에 복제할 수 있습니다.

즉, MongoDB가 최신 클라이언트 라이브러리를 사용했다면 Couchbase Server 쓰기 성능이 최소 10배 이상 향상되었을 것입니다. 2년 전 클라이언트 라이브러리(1.1.8)는 쓰기가 디스크에 기록되었는지 확인하기 전에 최소 100ms를 기다렸습니다. 이후 릴리스(1.4.x)에서는 10ms. 최신 릴리스(2.x)에서는 10µs입니다. 그렇기 때문에 항상 2년 전 버전이 아닌 최신 클라이언트 라이브러리를 사용하여 데이터베이스를 벤치마킹해야 합니다.

MongoDB 규칙 단일 노드 배포

MongoDB는 소규모 데이터 세트와 소수의 사용자로 구성된 개념 증명 또는 소규모 애플리케이션에 적합합니다. 분산 배포의 이점을 누릴 수 있는 더 많은 데이터, 더 많은 사용자, 더 높은 처리량/낮은 대기 시간 요구 사항이 있는 애플리케이션에는 Couchbase Server가 더 적합합니다. 실제로 기존의 관계형 데이터베이스가 필요한 확장성이나 성능을 제공하지 못하는 소규모 또는 대규모, 소비자 또는 기업, 소셜 또는 게임 등 미션 크리티컬 애플리케이션을 구동하기 위해 Couchbase Server가 선택되는 경우가 많습니다.

토론하기 해커 뉴스

참고 - 당사 벤치마킹 9노드 배포가 가능한 MongoDB 및 Couchbase Server.

작성자

게시자 Shane Johnson, 제품 마케팅 담당 이사, Couchbase

셰인 K 존슨은 Couchbase의 제품 마케팅 디렉터였습니다. Couchbase에 입사하기 전에는 Java 및 분산 시스템에 대한 배경 지식을 바탕으로 개발 및 전도 분야에서 다양한 역할을 수행했습니다. 그는 금융, 소매, 통신 및 미디어 업계의 조직과 컨설팅을 통해 데이터 및 분석을 위해 분산 시스템에 의존하는 아키텍처의 초안을 작성하고 구현했습니다.

모든 게시물

댓글 하나

  1. 소유자 4월 1, 2015에서 2:41 오후

    상대가 항상 질 수밖에 없는 성능 테스트를 하면서도 성능 테스트 없이 대응하겠다는 마케팅은 "아니 우리가 더 낫다!"라고 외치는 것과 비슷합니다. 우리는 약속합니다! 믿지 마세요!"라고 외치는 것과 같습니다.

    1. shanekj 4월 1, 2015에서 4:13 오후

      잘 이해가 되지 않습니다. 성능 테스트 없이 응답한다는 것이 무슨 뜻인가요?

    2. 크리스 앤더슨 4월 1, 2015에서 4:54 오후

      참고로, 몽고DB가 홍보한 벤치마크(이 블로그 게시물에 대한 답변입니다)는 더 큰 규모의 클러스터(9노드)로 이전 벤치마크에 대응하기 위해 실행되었습니다. 벤치마크는 여기에서 확인할 수 있습니다: http://news.avalonconsult.com/…

      TLDR은 9개 노드 클러스터에서 동시성이 높은 워크로드를 위한 것으로, Couchbase Server는 응답 속도 저하 없이 MongoDB보다 훨씬 더 많은 트래픽을 처리합니다. 이는 단일 노드 드래그-레이스보다 고객이 신경 쓰는 프로덕션 워크로드를 더 잘 나타냅니다.

  2. 아크말 쇼드리 4월 1, 2015에서 3:25 오후

    좋은 지적이지만 수년 전에 마이크 스톤브레이커가 한 말이 생각납니다: \"... 벤치마크를 설계하는 사람은 누구나 '승산이 없는' 상황에 처해 있으며, 즉 비판을 받을 수밖에 없습니다. 외부 관찰자들은 어떤 식으로든 벤치마크가 인위적이거나 불완전하다는 결함을 발견할 것입니다. 벤치마크에서 저조한 성적을 거둔 벤더는 무자비하게 비판받을 것입니다." IMHO가 정말 보고 싶은 것은 더 많은 YCSB 수치가 아니라 실제 고객 벤치마크입니다. 하지만 과거에 데이터베이스 성능 벤치마크 작업을 해본 적이 있어서 그 어려움을 잘 알고 있습니다.

    1. shanekj 4월 1, 2015에서 4:12 오후

      랄프, 어떻게 기만적이었나요?

    2. shanekj 4월 1, 2015에서 4:16 오후

      버드 라이트는 여전히 미국에서 가장 인기 있는 맥주입니다. 하지만 좋은 맥주는 아닙니다.

    3. 아크말 쇼드리 4월 1, 2015에서 4:56 오후

      랄프, 저는 카우치베이스에서 일하지 않습니다. 최근 Avalon 벤치마크 보고서에 대해서는 아직 읽어보지 않았기 때문에 언급할 수 없습니다. 주의해야 할 사항 DB-engines.com - 웹 언급/검색을 포함하는 인기도 등급이며 설치 수에 대해서는 언급하지 않습니다.

  3. Opsy 4월 1, 2015에서 4:26 오후

    YCSB는 업데이트 중에 10개 중 무작위 필드 하나를 업데이트합니다.

    MongoDB에는 단일 필드를 선택적으로 업데이트하는 업데이트 기능이 있지만(SQL UPDATE 문처럼), Couchbase에는 이 기능이 없습니다.

    따라서 문서를 먼저 읽지 않으면 기존 10개의 필드를 하나의 새 필드로 덮어쓰게 됩니다(작년에 게시한 Thumbtack 벤치마크가 그렇게 했습니다). 자체 Avalon 벤치마크는 필드 중 하나를 새 값으로 바꾸기 위해 문서를 읽지만 기존 문서를 대체하므로 그 사이에 발생한 모든 업데이트를 덮어쓰게 됩니다. 실제로 발생하는 모든 업데이트를 보존하려면 CAS를 사용하는 것이 맞습니다. MongoDB의 CAS는 장시간 문서를 업데이트해야 하는 경우(예: 사람이 문서를 편집하는 경우)에만 RDBMS에서와 동일하게 사용해야 합니다.

    1. shanekj 4월 1, 2015에서 4:38 오후

      솔직히 말해서 $set 명령은 쓰기 시나리오에 문서를 먼저 읽지 않은 여러 클라이언트가 같은 창에서 같은 문서의 다른 필드를 업데이트하는 것이 포함될 때 유용하다고 생각합니다.

      1. opsy 4월 1, 2015에서 5:30 오후

        YCSB에 익숙하지 않은 것 같습니다. 업데이트는 하나의 필드에만 새 값을 제공합니다. 전체 문서를 읽지 않은 경우 Couchbase에서 어떻게 업데이트하나요?

        UPDATE ycsbtable SET field6=newvalue WHERE primarykey=9999에 해당하는 Couchbase는 무엇인가요?

        1. shanekj 4월 1, 2015에서 6:09 오후

          맞습니다. 말씀드린 것처럼 $set 작업은 문서를 먼저 읽지 않고 특정 필드를 업데이트하는 애플리케이션에 유용하다고 생각합니다. 다른 애플리케이션의 경우에는 그렇지 않을 수도 있고 그렇지 않을 수도 있습니다. 예를 들어 사용자 프로필을 들 수 있습니다. 사용자가 자신의 프로필을 업데이트하려는 경우 애플리케이션이 먼저 프로필을 읽습니다. 프로필이 표시되고 사용자가 편집합니다. Couchbase Server를 사용하면 애플리케이션이 사용자 편집에 따라 읽은 문서를 수정한 다음 업데이트할 수 있습니다. MongoDB에서는 애플리케이션이 $set 명령을 사용할 수 있습니다. 이 맥락에서 애플리케이션은 MongoDB에서든 Couchbase Server에서든 문서를 먼저 읽습니다.

          1. Opsy 4월 3, 2015에서 8:42 오후

            자체 벤치마크가 문서를 읽은 다음 덮어쓰는 두 가지 작업을 수행하여 하나의 필드를 업데이트할 다른 방법이 없었고, 자체 벤치마크가 다른 스레드와의 충돌을 무시했습니다.

            코드가 잘못되었습니다.
            https://github.com/kruthar/YCS…

          2. shanekj 4월 4, 2015에서 12:11 오전

            문서를 먼저 읽지 않아도 됩니다.

            YCSB의 목표는 업데이트 작업의 성능을 측정하는 것입니다. 실제 애플리케이션에서는 문서가 이미 읽혀졌을 것입니다. 예를 들어 편집 양식을 채우려고 합니다. 읽기 성능을 측정하여 양식을 표시하는 데 걸리는 시간을 예측합니다. 양식이 제출되면 문서를 수정하고 업데이트합니다. 업데이트 성능을 측정하여 확인을 표시하는 데 걸리는 시간을 예측합니다. 문서를 만들고 YCSB로 해당 필드에 대한 데이터를 생성한 다음 업데이트를 수행할 수 있습니다. 문제가 해결되었습니다.

            Avalon 벤치마크는 MongoDB 또는 Couchbase Server에 대한 비교 및 스왑 작업을 수행하지 않았습니다. 부분 업데이트는 CAS 작업과 동일한 보장을 제공하지 않습니다. 이는 클라이언트가 이전 업데이트를 인식하지 못하는 경우 문서를 업데이트하지 못하도록 하는 낙관적 동시성 제어의 선택적 형태입니다.

            예를 들어 신용 카드 소지자의 계정입니다. 먼저 고객이 결제 필드를 확인하여 결제가 이루어졌는지 확인합니다. 아직 결제되지 않았습니다. 다음으로, 첫 번째 클라이언트가 결제 필드를 확인하는 동안 두 번째 클라이언트가 방금 처리되었으므로 결제 필드를 \"수신됨\"으로 업데이트합니다. 마지막으로 첫 번째 클라이언트는 두 번째 클라이언트가 수행한 업데이트를 인식하지 못하기 때문에 상태 필드를 \"늦음\"으로 업데이트합니다. 부분 업데이트가 있으면 좋지만 이 문제를 해결하지는 못합니다. 두 클라이언트가 서로 다른 필드를 동시에 업데이트할 수 있지만 결과는 유효하지 않습니다. 이것이 바로 CAS가 있는 이유입니다.

        2. shanekj 4월 1, 2015에서 6:29 오후

          그건 그렇고, 카우치베이스 서버 4.0의 경우 이것입니다:
          http://docs.couchbase.com/deve…

          업데이트 ycsbtable 사용 키 \"9999" 필드6 = \"newvalue\"

  4. guest 4월 3, 2015에서 8:02 오후

    적어도 벤치마크에는 모든 사람이 볼 수 있도록 사용된 코드가 포함되어 있어야 합니다. 직접 벤치마크를 실행했다면 코드를 보여주세요.

    1. shanekj 4월 3, 2015에서 11:32 오후

      GitHub 리포지토리의 URL이 포함되어 있어야 합니다. 여기 있습니다:
      https://github.com/kruthar/cou…

댓글 남기기