benchANT compares MongoDB and ScyllaDB architectures, with a focus on what the differences mean for performance and scalability NoSQL 데이터베이스를 선택할 때, 옵션은 압도적일 수 있습니다. 가장 인기있는 선택 중 하나는 사용하기 쉬운 MongoDB입니다.그러나 고성능 중심의 ScyllaDB는 상승하는 도전자 중 하나입니다. 이 보고서는 두 데이터베이스에 대해 더 자세히 기술적으로 살펴보고 있으며, 그들의 아키텍처를 독립적이고 기술적인 관점에서 비교합니다. 벤치 MongoDB와 ScyllaDB 모두 고가용성, 성능 및 확장성의 아키텍처를 약속합니다.하지만 이러한 목표를 달성하는 방법은 첫눈에 생각하는 것보다 훨씬 다릅니다. 예를 들어, 경험 보고서는 ScyllaDB가 분산 아키텍처 덕분에 AWS EC2 스팟 인스턴스에서 어떻게 쉽게 작동할 수 있는지 보여줍니다. 이러한 차이점을 강조하기 위해 우리는 내부 저장 아키텍처와 높은 가용성과 수평 확장성을 가능하게 하는 분산 아키텍처에 대한 심층적 인 토론을 제공합니다. 우리는 또한 이러한 차이의 영향을 정량화하는 벤치마크를 방금 발표했습니다. Note: DynamoDB vs MongoDB Benchmark 요약 읽기 이 비교 보고서를 다운로드 Read the DynamoDB vs MongoDB Benchmark Summary DynamoDB vs MongoDB Benchmark 요약 읽기 Download this Comparison Report 이 비교 보고서를 다운로드 MongoDB vs ScyllaDB의 스토리지 아키텍처에 대한 성능 관점 두 데이터베이스는 C++로 구현되며 XFS 파일 시스템의 사용을 권장하고 있습니다.MongoDB와 ScyllaDB는 또한 , Commit Log in ScyllaDB terminology 및 Oplog in MongoDB terminology. with write-ahead-logging, all operations are written to a log table before the operation is executed. the write-ahead-log serves as a source to replicate the data to other nodes, and it is used to restore data in case of failures because it is possible to 'replay' the operations to restore the data. 글쓰기-전제 로그링 개념 MongoDB는 데이터 저장 및 검색을 위해 기본 저장 엔진으로 B+-Tree 인덱스를 사용합니다. B+-Tree 인덱스는 정렬된 순서로 데이터를 저장하는 균형 잡힌 나무 데이터 구조이며 범위 기반 쿼리를 쉽게 수행할 수 있습니다. MongoDB는 복합 인덱스, 텍스트 인덱스 및 지상 공간 인덱스를 포함한 컬렉션에 여러 인덱스를 지원합니다. 배열 요소와 둥근 필드의 인덱싱은 복잡한 데이터 구조에 대한 효율적인 쿼리를 허용합니다. ScyllaDB는 데이터를 파편으로 나누어 특정 CPU에 노드의 총 데이터의 조각을 할당함으로써 관련 메모리 (RAM) 및 영구 저장 (NVMe SSD와 같은) 데이터를 분할합니다. ScyllaDB의 내부 저장 엔진은 디스크 영구 커미팅 로그를 디스크에 시간에 따라 뿌려진 메모리 기반 memtables와 함께 적용함으로써 write-ahead-logging 개념을 따릅니다. ScyllaDB는 초기, 초기 및 복합 인덱스를 지원합니다. 초기 인덱스는 노드 당 로컬 및 클러스터 당 글로벌입니다. 초기 인덱스는 해시 키와 해당 파티션이 저장되는 해시링 링으로 구성됩니다. 그리고 파티션 내에서 ScyllaDB는 분류 데이터 구조 (SSTable 이러한 다른 스토리지 아키텍처는 작업 부하를 처리하기 위해 사용할 수 있는 하드웨어의 다른 사용을 의미합니다.MongoDB는 사용할 수 있는 CPU 코어에 내부 스트레이트를 핀하지 않지만 분산된 스트레이트를 코어에 비결한 접근 방식을 적용합니다. CPU 아키텍처에서, 이것은 특히 대형 서버에서 성능 악화를 일으킬 수 있습니다.This can cause a performance degradation, especially for large servers because threads can dynamically be assigned to cores on different sockets with different memory nodes. 이것은 그것이 책임 스레드를 특정 코어에 핀 하 고 다른 코어와 메모리 공간 사이의 전환을 방지 하는 것을 허용 합니다.이 결과로, 셔드 키는 셔드에 걸쳐 동등한 데이터 분포를 보장 하 고 뜨거운 셔드를 방지 하기 위해 신중 하 게 선택 해야 합니다. 이는 지연 민감한 및 무감각한 쿼리를 위한 내장된 우선 순위 클래스를 제공하고 하나의 노드에 있는 격자들에 걸쳐 조정된 I/O 스케줄링을 제공하여 디스크 성능을 극대화합니다. 마지막으로, ScyllaDB의 설치 스크립트는 사용 가능한 리소스에 따라 최적의 데이터베이스 구성을 적용함으로써 성능 자동 조정 단계를 제공합니다. 숫자 기반 Shard Per Core 접근법 I/O 스케줄 ScyllaDB는 사용자가 데이터가 DB 캐시에 있어야 하는지 또는 거의 액세스하지 않는 파티션에서 데이터를 교차해야 하는지 여부를 제어할 수 있도록 해줍니다.ScyllaDB는 클라이언트가 데이터를 소유하는 노드 및 CPU 코어(shard)에 액세스할 수 있도록 해줍니다.이것은 낮은 지연, 일관된 성능 및 완벽한 로드 균형을 제공합니다.ScyllaDB는 또한 특정 중요한 워크로드에 대한 낮은 지연을 보장하기 위해 사용자에게 다른 워크로드에 대한 다른 SLA를 제공하는 ' 워크로드 우선화'도 제공합니다. MongoDB 분산 아키텍처 – 높은 가용성과 확장성을 위한 두 가지 운영 모드 MongoDB 데이터베이스 아키텍처는 다음 섹션에서 설명하는 두 가지 클러스터 모드를 제공합니다 : 복제 세트 클러스터는 높은 가용성을 목표로하고, 분해 된 클러스터는 수평 확장성과 높은 가용성을 목표로합니다. Replica Set Cluster: 높은 가용성과 제한된 확장성 MongoDB 복제 세트의 개념에 의해 높은 가용성을 가능하게 합니다. MongoDB 복제 세트는 Primary-Secondary 노드의 개념을 따르며, primary가 WRITE 작업을 처리하는 경우에만 해당됩니다. secondaries는 데이터의 복사본을 보유하고 READ 작업만을 처리할 수 있습니다. common replica set deployment은 2개의 secondaries로 구성되지만, 추가 secondaries는 가용성을 높이거나 읽기 힘든 워크로드를 확장하기 위해 추가로 추가될 수 있습니다. MongoDB는 1개의 복제 세트 내에서 최대 50개의 secondaries를 지원합니다. secondaries는 이전의 primary에서 실패하는 경우에 기본으로 선택됩니다. 지리 배포에 관해서는 MongoDB는 데이터 센터 실패의 경우 높은 가용성을 보장하기 위해 복제 집합에 대한 지리 배포를 지원합니다.In this context, secondary instances can be distributed across multiple data centers, as shown in the following figure.In addition, secondaries with limited resources or network constraints can be configured with a priority to control their electability as primary in case of a failure. Sharded Cluster: Horizontal Scalability and High Availability with Operational Complexity 부근의 호텔 MongoDB는 글쓰기 강렬한 워크로드와 데이터 크기가 증가하는 작업을 처리하기 위해 여러 기본 인스턴스에 데이터를 분할함으로써 수평 스케일링을 지원합니다.Shared cluster에서는 1개의 기본 및 여러 차원으로 구성된 각각의 복제 세트가 분할을 나타냅니다.Shared는 MongoDB 4.4 차원으로서 또한 헤드된 읽기 옵션을 사용하여 읽기 요청을 처리하는 데 사용할 수 있습니다. Sharding을 사용하려면 추가 MongoDB 노드 타입이 필요합니다.To enable sharding, additional MongoDB node types are required: mongos 인스턴스는 쿼리 라우터로 작용하여 클라이언트 응용 프로그램과 분해된 클러스터 사이의 인터페이스를 제공합니다. 그 결과 클라이언트는 결코 쿼리 라우터를 통해서만, 결코 쿼리 라우터와 직접 통신하지 않습니다. 쿼리 라우터 (Query Router) 쿼리 라우터가 클라이언트 드라이버의 직접 인터페이스이기 때문에 클러스터의 접근성을 보장하기 위해 여러 쿼리 라우터를 배포하는 것이 좋습니다. 쿼리 라우터의 수에 제한이 없지만, 그들이 구성 서버와 자주 통신하기 때문에, 너무 많은 쿼리 라우터가 구성 서버를 과부하 할 수 있음을 주목해야합니다. Config 서버는 모든 데이터와 구성 요소의 상태와 조직을 포함한 분할 클러스터의 메타데이터를 저장합니다. 메타데이터에는 각 분할의 조각 목록과 조각을 정의하는 범위가 포함됩니다. Config 서버는 높은 가용성을 보장하기 위해 복제 세트 자체로 배포되어야합니다. MongoDB의 데이터 스크래딩은 컬렉션 수준에서 수행되며, 컬렉션은 스크래드 키를 기반으로 스크래딩할 수 있습니다. MongoDB는 스크래드 키를 사용하여 어떤 문서가 어느 스크래드에 속하는지 결정합니다.Common shard key choices include the _id field and a field with a high cardinality, such as a timestamp or user ID. MongoDB supports three sharding strategies: range based, hash based and zone based. 샤드 키 값에 따라 샤드 사이의 문서를 분할합니다.이 방법은 샤드 키 값이 있는 문서를 서로 가깝게 유지하고, 예를 들어 시간 시리즈 데이터에 대한 범위 기반 쿼리에서 잘 작동합니다. 샤드 사이의 샤드 문서는 샤드 사이의 샤드의 균일한 분포를 보장하여 글쓰기 워크로드를 선호합니다. 샤드 사이드는 개발자가 사용자 지정 샤드 규칙을 정의하여, 예를 들어 가장 관련된 데이터가 응용 프로그램 서버에 가장 가까운 샤드에 있는지 확인할 수 있습니다. 또한, 분해된 클러스터는 다음 그림에서 묘사한 바와 같이 데이터 센터 실패를 극복하기 위해 지리적으로 분산된 설정에 배포될 수 있다. ScyllaDB 아키텍처 - 높은 가용성 및 수평 확장성을 위한 멀티프리미어 MongoDB와 달리, ScyllaDB는 하나의 기본 노드와 여러 초기 노드가있는 고전적인 RDBMS 아키텍처를 따르지 않지만, 모든 데이터가 여러 노드에 걸쳐 체계적으로 분포되고 클러스터를 형성하여 복제되는 분산 구조를 사용합니다. 클러스터는 데이터가 배포되는 가상 링 아키텍처로 구성된 상호 연결된 노드의 집합입니다. 링은 물리적 노드에 할당된 토큰의 범위를 나타내는 vNodes로 나누어져 있으며 키 스페이스에 대한 복제 요소 세트에 따라 물리적 노드에 대해 복제됩니다. 모든 노드는 다중 기본적인 의미에서 동등하게 간주됩니다. 정의된 리더가 없으면 클러스터에는 단일 실패 지점이 없습니다. 노드는 개별적인 현지 서버, 또는 더 큰 물리적 서버의 하드웨어 하위 세트로 구성된 가상 서버 (공공공용 클라우드 인스턴스)가 될 수 있습니다. 각 노드에서 데이터는 더 나아가 파티션으로 분할됩니다. 파티션은 대부분 독립 모든 노드가 서로 통신을 통해 이 프로토콜은 어느 파티션에서 어떤 데이터를 작성하고 인덱스를 사용하여 오른쪽 파티션에서 데이터 레코드를 검색하는지 결정합니다.This protocol decides in which partition which data is written and searches for the data records in the right partition using the indexes. GOSIP 프로토콜 ScyllaDB의 아키텍처는 여러 서버 및 영역을 통한 간단한 수평 분할을 위해 만들어졌습니다. ScyllaDB의 분할은 테이블 수준에서 수행되며, 테이블은 분할 키를 기반으로 분할될 수 있습니다. 분할 키는 단일 열이거나 여러 열의 복합체가 될 수 있습니다. ScyllaDB는 또한 범위 기반 분할을 지원하며, 분할 키 값 범위에 따라 줄이 분할을 통해 분배되며, 데이터를 동등하게 분배하고 핫스팟을 피하기 위해 해시 기반 분할을 지원합니다. 또한 ScyllaDB는 여러 데이터 센터에 데이터를 복제하여 더 높은 가용성과 낮은 지연률을 제공합니다.In this multi-data-center or multi-region setup, the data between data centers is asynchronously replicated. 클라이언트 측면에서 애플리케이션은 다중 데이터 센터 배포에 대해 알거나 알지 못할 수 있으며, 다중 데이터 센터(s)에 대한 인식에 대해 애플리케이션 개발자가 결정할 수 있습니다.This can be configured via the read and write consistency options that define whether queries are executed against a single data center or across all data centers. Load balancing in a multi datacenter setup depends on the available settings within the specific programming language driver. MongoDB 및 ScyllaDB의 분산 아키텍처에 대한 비교적 확장성 관점 (Comparative Scalability Viewpoint on the Distributed Architectures of MongoDB and ScyllaDB) 확장성에 관해서는 ScyllaDB와 MongoDB의 크게 다른 배포 접근 방식이 고려되어야 하며, 특히 현장 또는 IaaS에서 실행되는 자율 관리 클러스터의 경우 MongoDB의 아키텍처는 복제 세트의 부작용 수를 늘리면서 읽기 힘든 워크로드를 쉽게 확장할 수 있습니다. 그럼에도 불구하고, 상당한 쓰기 비율을 가진 워크로드를 확장하기 위해서는 복제 집합이 분해된 복제 집합으로 변환되어야 하며, 이것은 여러 가지 도전을 초래합니다. 첫째, 두 가지 추가 MongoDB 서비스가 필요합니다: n 쿼리 라우터 (mongos)와 높은 가용성을 보장하기 위해 복제 서버의 복제 집합. 결과적으로, 분해를 허용하기 위해 훨씬 더 많은 자원이 필요합니다. 또한, 운영 복잡성은 확실히 증가합니다. 예를 들어, 세 분할이있는 분해된 클러스터는 세 분할 인스턴스의 복제 집합, 세 분할 서버와 세 분할의 복제 집합을 필요로합니다. 두 번째 도전은 분할된 클러스터에서 데이터를 분할하는 것입니다. 여기서 MongoDB는 분할된 클러스터에 새 분할이 추가되면 자동으로 데이터의 재분할을 유발하는 끊임없이 실행되는 배경 작업을 적용합니다. 분할은 클러스터에 새 분할이 추가되면 일어나지 않지만 특정 내부 경계가 도달되면 발생합니다. 결과적으로 분할의 수를 늘리는 것은 클러스터를 즉시 확장하지만 확장 효과가 지연 될 수 있습니다. MongoDB 버전 5.0까지 MongoDB 엔지니어들은 스스로 분할하지 않고 가능하면 더 큰 기계로 수평적으로 확장하는 것을 권장합니다. ScyllaDB 클러스터를 확장하는 것은 ScyllaDB의 다중 기본 아키텍처 덕분에 사용자에게 비교적 쉽고 투명합니다. 여기서 각 노드는 동등하며, 클러스터를 수백 개의 노드로 확장하는 데 추가 서비스가 필요하지 않습니다. 또한, 데이터 분할은 클러스터에 새로운 노드가 추가되면 시작됩니다. 이 맥락에서 ScyllaDB는 MongoDB에 비해 명확한 이점을 제공합니다. 첫째, 일관된 해시 접근 방식 덕분에 데이터는 전체 클러스터, 단지 노드의 하위 집합을 통해 분할 될 필요가 없습니다. 둘째, 분할은 새로운 노드를 추가함으로써 시작되며, 이는 확장 작업의 타이밍을 촉진합니다. 이것은 분할이 클러스터에 추가 부하를 부 주요 확장성 차이점은 다음 표에 요약되어 있습니다: The main scalability differences are summarized in the following table: 결론 및 Outlook 두 개의 분배를 비교할 때 데이터베이스에서, 당신은 항상 몇 가지 유사점을 발견하지만, 또한 많은 상당한 차이를 발견합니다. . 두 데이터베이스는 유사한 사용 사례를 다루고 유사한 제품 및 커뮤니티 전략을 가지고 있습니다.하지만 기술 측면에서 다른 접근 방식과 초점을 볼 수 있습니다. 두 데이터베이스는 분산 아키텍처를 통해 높은 가용성을 가능하게하기 위해 구축되었습니다.하지만 대상 워크로드에 관해서는 MongoDB는 단일 노드 또는 중소 워크로드에 적합한 복제 집합 배포를 쉽게 시작할 수 있습니다. 노스카 ScyllaDB vs MongoDB ScyllaDB는 간단하고 높은 확장성, 높은 전송량, 낮고 안정적인 지연 시간, 그리고 다중 데이터 센터 배포의 모든 것을 요구하는 성능 중요 한 워크로드를 명확하게 해결합니다.This is also shown by data intensive use cases of companies such as Discord, Numberly or TRACTIAN that migrated from MongoDB to ScyllaDB to successfully solve performance problems. 그리고 각각의 성능 능력에 대한 추가 통찰력을 제공하기 위해, 우리는 MongoDB Atlas 및 ScyllaDB Cloud의 성능, 확장성 및 비용을 조사하는 별도의 벤치마크 보고서에서 투명하고 재현 가능한 성능 비교를 제공합니다. 추가 ScyllaDB vs. MongoDB 비교 세부 사항 전체 보기 이 기술 비교의 확장 된 버전을 위해, 자세한 비교를 포함하여: BenchANT MongoDB vs ScyllaDB 비교 데이터 모델 원하는 언어 사용 사례 및 고객 예제 데이터 일관성 옵션 최초의 운영 경험
