공식화되었습니다. 선도적인 NoSQL 데이터베이스 공급업체인 DataStax, MongoDB, Couchbase가 서로를 견제하고 있습니다.
지난 30일 동안
- 카우치베이스는 벤치마크 3월 19일에 출시되었습니다.
- 몽고DB는 이에 대한 대응으로 벤치마크 3월 31일에 출시되었습니다.
- 데이터스택스는 이에 대해 벤치마크 4월 13일에 출시되었습니다.
경쟁력 있는 벤치마크를 수행하는 것이 중요합니다. 벤치마크를 후원하면 특정 구성의 특정 시나리오에서 데이터베이스가 얼마나 잘 작동하는지 알 수 있습니다. 경쟁사가 벤치마크를 후원하면 다른 구성의 다른 시나리오에서 데이터베이스가 얼마나 잘 작동하는지 알 수 있습니다. 즉, 우리 모두는 벤치마크가 적절한 구성으로 실제 시나리오를 대표할 수 있도록 커뮤니티에 빚을 지고 있습니다. 그러기 위해서는 투명해야 합니다.
DataStax가 벤치마크의 중요성을 인식한 것은 기쁘지만, 이 벤치마크는 Couchbase Server 성능을 정확하게 나타내지는 않습니다. 이 벤치마크의 투명성 부족으로 인해 그 유효성에 대한 불확실성을 야기하는 많은 미답변 질문이 제기됩니다.
1) Couchbase Server에 캐시가 잘못 구성된 이유는 무엇인가요?
Couchbase Server는 캐시 최적화를 위해 기본 옵션인 "값" 추출과 "전체" 추출의 두 가지 옵션을 지원합니다. 이 벤치마크에서는 이 시나리오에 대해 잘못된 캐시 최적화인 "전체" 내보내기를 활성화하여 Couchbase Server의 읽기 성능을 크게 제한했습니다.
카우치베이스 서버는 문서가 삽입될 때 메타데이터와 값을 캐시합니다.
"값" 내보내기가 활성화되어 있고 메모리가 충분하지 않은 경우 Couchbase Server는 다른 문서의 값을 내보내지만 해당 메타데이터는 유지합니다.
"전체" 내보내기가 활성화되어 있고 메모리가 충분하지 않은 경우 Couchbase Server는 메타데이터와 다른 문서의 값을 모두 내보냅니다.
이 벤치마크의 시나리오에서는 5억 개의 모든 문서에 대한 메타데이터를 캐시하기에 충분한 메모리가 있었기 때문에 '값' 추출을 권장합니다. 이렇게 하면 데이터가 디스크에 저장된 위치를 파악하기 위한 불필요한 디스크 IO를 제거하여 읽기 성능이 향상되었을 것입니다.
Couchbase Server와 MongoDB는 모두 더 나은 읽기 성능을 제공합니다. 이 벤치마크에서 읽기 성능이 저조한 이유는 무엇일까요?
숫자가 맞지 않습니다. 메모리에서 차지하는 데이터의 비율이 더 크고 문서 크기가 훨씬 작은 Couchbase Server의 성능은 어떻게 더 나빠졌을까요? Couchbase 벤치마크에서 문서의 크기는 1K였습니다. DataStax 벤치마크에서는 100바이트였습니다.
카우치베이스 서버 성능
(1) 카우치베이스 벤치마크 및 (2) 데이터스택스 벤치마크
| 벤치마크 | 코어당 초당 작업 수 | 노드당 데이터 | 노드당 메모리 | 노드 | 노드당 코어 수 |
| 1 카우치베이스 후원 | 4,600 | 32GB | 10GB | 9 | 8 |
| 2 DataStax 후원 | 375 | 50GB | 23GB | 8 | 4 |
2) 카우치베이스 서버 YCSB 클라이언트가 오래된 클라이언트 라이브러리를 기반으로 한 이유는 무엇인가요?
GitHub 리포지토리에 따르면 이 벤치마크에 사용된 Couchbase Server용 YCSB 클라이언트는 Couchbase Server 2.5용 이전 클라이언트 라이브러리를 기반으로 합니다. 이 클라이언트는 현재 Couchbase Server 3.0용 클라이언트 라이브러리를 기반으로 했어야 합니다. 이전 클라이언트는 데이터가 디스크에 기록되었는지 확인하기 전에 최소 10밀리초를 기다렸습니다. 현재 클라이언트는 최소 10마이크로초만 기다립니다.
2세대 클라이언트를 사용했다면 카우치베이스 서버의 쓰기 성능이 더 좋았을 것입니다.
3) 카산드라에서 복제가 비활성화 된 이유는 무엇인가요?
DataStax는 복제 없이 Cassandra를 구성했는데, 이는 실제 환경에서는 권장되지 않습니다. 이는 용납할 수 없는 수준의 위험입니다. 노드에 장애가 발생하면 데이터를 사용할 수 없게 됩니다. Cassandra의 쓰기 성능을 개선하기 위해 복제를 비활성화했나요?
Cassandra는 결국 기본적으로 일관성을 유지합니다. Couchbase Server와 MongoDB는 기본적으로 강력한 일관성을 적용합니다. Cassandra가 데이터를 복제하도록 구성되면 일관성에 문제가 생길 수 있습니다. 쿼럼을 통해 강력한 일관성을 구성하면 성능에 부정적인 영향을 미칠 수 있습니다.
Couchbase Server는 기본적으로 데이터를 두 개의 노드에 복제하며, 소유자와 두 개의 복제본에 저장됩니다. MongoDB는 데이터를 여러 노드에 복제하며, 기본 노드와 보조 노드에 저장됩니다. 이 벤치마크에는 Couchbase Server에 대해 구성된 복제본 수나 MongoDB에 대해 배포된 보조 노드 수는 명시되어 있지 않습니다. 저희도 알 수 없기 때문에 투명성이 중요한 것입니다. 이 정보 없이는 성능 테스트를 재현할 수 없습니다.
4) 카산드라 글씨는 내구성이 있었나요?
카우치베이스 서버와 몽고DB는 내구성 쓰기를 위해 구성되었습니다. Cassandra가 내구성 쓰기를 사용하도록 구성되었는지 여부는 확실하지 않습니다. 만약 그렇지 않다면, Cassandra는 내구성을 희생하는 대신 상당한 성능 이점을 누릴 수 있습니다. 기본적으로 Cassandra 쓰기는 내구성이 없습니다.
5) 내구성을 확보하기 위해 복제를 사용하지 않은 이유는 무엇인가요?
내구성을 확보하려면 복제를 활성화하는 것이 좋습니다. 데이터를 여러 노드에 복제하면 노드에 장애가 발생해도 데이터가 손실되지 않으므로 내구성이 높아집니다. 이 벤치마크에서는 데이터가 단일 노드에 저장되므로 디스크에 기록되지 않는 한 내구성이 없습니다. 그러나 Cassandra나 Couchbase Server와 같은 분산 데이터베이스는 여러 노드에 데이터를 저장할 수 있으며, 이를 권장합니다.
추가 크레딧: 몽고DB 방어
맞습니다, 저희는 MongoDB를 방어하고 있습니다.
먼저, 키가 증분식("user1", "user2", "user3")이라는 것을 알고 범위 기반 파티셔닝으로 MongoDB를 구성한 DataStax에 놀랐습니다. MongoDB 2.4 소개 해시 기반 파티셔닝.
둘째, DataStax가 몽고DB의 릴리스 후보를 포함하는 벤치마크를 발표한 것에 놀랐습니다. 저희는 벤치마크가 일반적으로 사용 가능한 릴리스로 제한되어야 한다고 생각합니다. 마일스톤, 후보, 알파 또는 베타 릴리스는 포함되지 않아야 합니다. 카우치베이스 벤치마크 에는 GA 릴리스를 기다렸기 때문에 몽고DB 3.0이 포함되어 있습니다.
셋째, 이 수치는 MongoDB 읽기 성능을 잘 나타내지 않는다고 생각합니다. 결국, MongoDB는 Couchbase 벤치마크에서 초당 최대 74,000회의 작업을 실행했습니다. 이는 이 벤치마크에서 보여준 초당 2K 작업보다 훨씬 많은 수치입니다. 그 이유는 알 수 없지만, 이 벤치마크는 투명성이 부족하기 때문입니다.
결론: 결론: 벤치마크가 가치를 가지려면 투명하고 적절하게 구성되어야 합니다.
벤더, 잠재 고객 및 커뮤니티가 벤치마크를 쉽게 재현할 수 있도록 하는 것이 중요합니다. 그러기 위해서는 공개된 벤치마크에 모든 클라이언트 구성과 모든 데이터베이스 구성이 포함되어야 합니다. 그러나 투명성이 부족하기 때문에 이 벤치마크를 재현하기는 어려울 것입니다.
즉, 데이터베이스를 벤치마킹하는 것은 어렵습니다. 자체 데이터베이스를 구성하는 방법을 아는 것만으로는 충분하지 않으며 다른 데이터베이스를 구성하는 방법도 알고 있어야 합니다. Cassandra를 벤치마킹한 후, 후속 벤치마크에서 더 나은 구성 방법을 배웠습니다. 데이터스택스가 Couchbase Server를 더 잘 구성하는 방법을 배웠기를 바랍니다.
필요한 경우 다음 벤치마킹을 기꺼이 도와드리겠습니다.
토론하기 해커 뉴스
