Azure Cosmos DB for Apache Cassandra에 대해 자주 묻는 질문

다음은 Cassandra 서비스용 API와 Apache Cassandra 간의 몇 가지 주요 차이점입니다.

• Apache Cassandra는 파티션 키 크기에서 100MB 한도를 권장합니다. Azure Cosmos DB용 API for Cassandra는 파티션당 최대 20GB를 허용합니다.
• Apache Cassandra를 사용하여 지속형 커밋을 사용하지 않도록 설정할 수 있습니다. 커밋 로그에 대한 쓰기를 건너뛰고 메모리 내 데이터 구조로 직접 이동합니다. 이로 인해 메모리 내 데이터 구조가 디스크의 SSTable로 플러시되기 전에 노드가 다운되면 데이터가 손실될 수 있습니다. Azure Cosmos DB는 항상 지속형 커밋을 수행하여 데이터 손실을 방지할 수 있습니다.
• Apache Cassandra는 워크로드에 많은 바꾸기나 삭제가 포함된 경우 성능이 저하될 수 있습니다. 이유는 최신 데이터를 가져오기 위해 읽기 워크로드가 건너뛰어야 하는 삭제 표식 때문입니다. API for Cassandra는 워크로드에 많은 바꾸기나 삭제가 있어도 읽기 성능이 저하되지 않습니다.
• 바꾸기 워크로드가 많은 시나리오 중에는 디스크의 SSTable을 병합하기 위해 압축을 실행해야 합니다. (Apache Cassandra의 쓰기는 추가 전용이므로 병합이 필요합니다. 여러 업데이트는 주기적으로 병합해야 하는 개별 SSTable 항목으로 저장됩니다.) 이 경우 압축하는 동안 읽기 성능이 저하될 수도 있습니다. API가 압축을 구현하지 않으므로 API for Cassandra에서는 이 성능 영향이 발생하지 않습니다.
• Apache Cassandra에서는 복제 요소를 1로 설정할 수 있습니다. 그러나 데이터가 있는 유일한 노드가 다운되면 가용성이 낮아집니다. 항상 복제 인자 4(쿼럼 3)가 있기 때문에 Azure Cosmos DB용 Cassandra용 API에는 문제가 되지 않습니다.
• Apache Cassandra에서 노드를 추가하거나 제거하려면 수동 개입이 필요할 뿐 아니라 기존 노드가 토큰 범위 중 일부를 새 노드로 이동하는 동안 새 노드에서 CPU 사용량이 높아집니다. 이 경우는 기존 노드를 해제할 때와 동일합니다. 그러나 API for Cassandra는 서비스나 애플리케이션에서 관찰되는 문제없이 스케일 아웃됩니다.
• Apache Cassandra처럼 클러스터의 각 노드에서 num_tokens 설정할 필요가 없습니다. Azure Cosmos DB는 노드와 토큰 범위를 완전히 관리합니다.
• API for Cassandra는 완전 관리형 API입니다. Apache Cassandra에서 사용되는 복구 및 서비스 해제와 같은 명령은 필요하지 않습니다.

Azure Cosmos DB용 Cassandra용 API는 CQL(Cassandra Query Language) m 버전 3.x를 지원합니다. CQL 호환성은 퍼블릭 Apache Cassandra GitHub 리포지토리를 기반으로 합니다. 다른 프로토콜 지원에 대한 피드백이 있는 경우 askcosmosdbcassandra@microsoft.com으로 이메일을 보내세요.

Azure Cosmos DB는 테이블을 만드는 위치인 Azure Portal 또는 CQL에 따라 컨테이너의 기본 처리량을 설정합니다.

Azure Cosmos DB는 작업에 대한 상한을 사용하여 성능 및 대기 시간을 보장합니다. 이 보장은 엔진이 테넌트 작업에서 거버넌스를 적용할 수 있는 경우 가능합니다. 처리량을 설정하면 플랫폼에서 이 용량을 예약하고 작업 성공을 보장하므로 보장된 처리량 및 대기 시간을 가져올 수 있습니다. 처리량을 탄력적으로 변경하여 애플리케이션의 계절성을 활용하고 비용을 절감할 수 있습니다.

처리량 개념은 Azure Cosmos DB의 요청 단위에 설명되어 있습니다. 테이블의 처리량은 기본 물리적 파티션에 동일하게 분산됩니다.

Azure Cosmos DB는 처리량을 제공하는 기준으로 초당 요청 단위(RU/s)를 사용합니다. 기본적으로 CQL을 통해 생성된 테이블에는 400RU가 있습니다. Azure Portal에서 RU를 변경할 수 있습니다.

CQL

CREATE TABLE keyspaceName.tablename (user_id int PRIMARY KEY, lastname text) WITH cosmosdb_provisioned_throughput=1200

.NET

int provisionedThroughput = 400;
var simpleStatement = new SimpleStatement($"CREATE TABLE {keyspaceName}.{tableName} (user_id int PRIMARY KEY, lastname text)");
var outgoingPayload = new Dictionary<string, byte[]>();
outgoingPayload["cosmosdb_provisioned_throughput"] = Encoding.UTF8.GetBytes(provisionedThroughput.ToString());
simpleStatement.SetOutgoingPayload(outgoingPayload);

Azure Cosmos DB는 작업에 대한 상한을 사용하여 성능 및 대기 시간을 보장합니다. 이 보장은 엔진이 테넌트 작업에서 거버넌스를 적용할 수 있는 경우 가능합니다. 처리량을 설정하면 플랫폼에서 이 용량을 예약하고 작업 성공을 보장하므로 보장된 처리량 및 대기 시간을 가져올 수 있습니다.

이 용량을 초과하면 용량이 다 사용되었음을 나타내는 다음 오류 메시지가 표시됩니다.

0x1001 오버로드됨: “요청 빈도가 높아서” 요청을 처리할 수 없습니다.

어떤 작업 및 해당 볼륨으로 인해 이 문제가 발생한 것인지 확인해야 합니다. Azure Portal에서 메트릭을 통해 프로비저닝된 용량을 초과하는 사용된 용량을 파악할 수 있습니다. 그런 다음, 모든 기본 파티션에서 용량이 거의 동일하게 사용되는지 확인해야 합니다. 한 파티션에서 처리량의 대부분을 사용할 경우 워크로드가 한쪽으로 기웁니다.

개별 파티션 또는 전체 파티션이 몇 시간, 며칠, 일주일 동안 처리량을 얼마나 사용하는지 보여 주는 메트릭을 사용할 수 있습니다. 자세한 내용은 Azure Cosmos DB에서 메트릭을 사용하여 모니터링 및 디버깅을 참조하세요.

진단 로그에 대한 내용은 Azure Cosmos DB 진단 로깅 문서에 설명되어 있습니다.

예. 파티션 키는 엔터티를 올바른 위치에 배치하는 데 사용됩니다. Azure Cosmos DB에서는 물리적 파티션에 저장된 올바른 논리 파티션을 찾는 데 사용됩니다. 분할 개념은 Azure Cosmos DB의 파티션 및 확장 문서에 잘 설명되어 있습니다. 여기서 중요한 점은 논리 파티션이 20GB 제한을 초과해서는 안 된다는 것입니다.

Azure Cosmos DB는 SLA(서비스 수준 약정)를 기반으로 하는 시스템입니다. 대기 시간, 처리량, 가용성, 일관성을 보장할 뿐만 아니라 무제한 스케일링을 제공합니다. 이 무제한 스토리지는 분할을 주요 개념으로 사용하는 데이터의 수평 스케일 아웃을 기반으로 합니다. 분할 개념은 Azure Cosmos DB의 파티션 및 확장 문서에 잘 설명되어 있습니다.

논리 파티션당 엔터티 또는 항목 수에 대한 20GB 한도를 준수해야 합니다. 애플리케이션이 원활하게 확장할 수 있도록 하려면 단일 파티션에 대한 모든 정보를 저장 및 쿼리하여 핫 파티션을 만들지 않는 것이 좋습니다. 이 오류는 하나의 파티션 키에 너무 많은 데이터가 있어서(20GB 초과) 데이터가 한쪽으로 기울어진 경우에만 발생합니다. 스토리지 포털을 사용하여 데이터 분포를 확인할 수 있습니다. 이 오류를 해결하는 방법은 테이블을 다시 만들고 더 나은 데이터 분포를 허용하는 세분화된 기본 파티션 키를 선택하는 것입니다.

Azure Cosmos DB는 스토리지를 수평으로 확장하여 무제한 데이터를 저장할 수 있습니다. 이 스토리지는 처리량과는 별개입니다. 예, 항상 API for Cassandra를 통해 올바른 기본/파티션 키를 지정하여 키와 값을 저장하고 검색할 수 있습니다. 이 개별 키는 자체 논리 파티션을 가져오고 문제없이 실제 파티션 위쪽에 배치됩니다.

예, API for Cassandra를 사용하여 테이블을 두 개 이상 만들 수 있습니다. 이러한 각 테이블은 처리량 및 스토리지에 대한 단위로 처리됩니다.

Azure Cosmos DB는 데이터 및 컨트롤 플레인 작업을 위한 리소스 관리 시스템입니다. 컬렉션, 테이블과 같은 컨테이너는 지정된 처리량 용량에 대해 프로비저닝되는 런타임 엔터티입니다. 연속으로 빠르게 이 컨테이너를 만드는 작업은 필요한 작업이 아니며 제한될 수 있습니다. 테이블을 즉시 삭제하거나 만드는 테스트가 있다면 테이블 사이에 공간을 충분히 확보하세요.

테이블 수에는 실제 한도가 없습니다. 만들어야 하는 테이블이 일상적인 수십 또는 수백 개가 아니라 매우 많은 경우(총 크기가 일정하게 10TB 데이터를 초과하는 경우) askcosmosdbcassandra@microsoft.com으로 이메일을 보내주세요.

키 공간은 메타데이터 컨테이너이기 때문에 키 공간 수에는 실제 한도가 없습니다. 키 공간이 매우 많은 경우 askcosmosdbcassandra@microsoft.com으로 이메일을 보내주세요.

예. 균일하게 분산된 파티션의 경우 스토리지 용량은 자동으로 관리되고 더 많은 데이터를 밀어 넣을 때 증가합니다. 따라서 노드 관리 및 프로비저닝 등의 작업을 수행하지 않고도 필요한 만큼의 데이터를 안심하고 가져올 수 있습니다. 그러나 수많은 즉각적인 데이터 증가를 예상하는 경우 더 낮게 시작하고 즉시 늘리기보다는 예상 처리량을 직접 프로비전하는 것이 더 합리적입니다.

Azure Cosmos DB용 API for Cassandra는 작업을 실행하기 위한 프로토콜 수준 호환성을 제공합니다. 관리, 모니터링 및 구성의 복잡성을 숨깁니다. 개발자/사용자인 경우 가용성, 삭제 표식, 키 캐시, 행 캐시, bloom 필터, 다양한 기타 설정에 관해 걱정할 필요가 없습니다. API for Cassandra는 구성 및 관리의 오버헤드 없이 필요한 읽기 및 쓰기 성능을 제공하는 데 중점을 둡니다.

API for Cassandra는 처리량과 스토리지에 대한 탄력성 요구에 맞게 용량 계획과 대응을 단순화합니다. Azure Cosmos DB를 사용하여 필요한 처리량을 프로비저닝합니다. 그런 다음, 노드 추가, 삭제 또는 관리에 관한 걱정 없이 하루에 원하는 만큼 여러 번 스케일 업 및 다운할 수 있습니다. 노드 및 클러스터 관리에 도구를 사용할 필요가 없습니다.

Azure Cosmos DB는 가용성과 짧은 대기 시간의 이유로 전역 배포를 기본 제공합니다. 복제본이나 다른 항목을 설정할 필요가 없습니다. 쓰기는 작성 지역에서 항상 지속해서 쿼럼으로 커밋되며 성능을 보장합니다.

Azure Cosmos DB는 읽기, 쓰기, 처리량에 대한 성능을 보장합니다. 따라서 구성 설정에 관여하고 실수로 조작하는 것에 관해 걱정할 필요가 없습니다. 해당 설정에는 bloom 필터, 캐싱, 읽기 복구 기회, gc_grace, 압축 memtable_flush_period가 포함됩니다.

예, TTL이 지원됩니다.

Azure Cosmos DB는 인프라를 관리하고 모니터링할 걱정 없이 생산성을 높이는 데 도움이 되는 플랫폼 서비스입니다. 예를 들어, 초기에 다양한 도구를 사용하여 노드 상태, 복제본 상태, gc, OS 매개 변수를 모니터링할 필요가 없습니다. 포털 메트릭에서 사용 가능한 처리량을 통해 제한에 근접했는지 확인한 다음, 해당 처리량을 늘리거나 줄이면 됩니다. 마케팅 목록의 구성원을 관리할 수 있습니다.

• SLA 모니터링
• 메트릭 사용
• 진단 로그 사용

CQLv3을 사용하는 Apache Cassandra SDK의 클라이언트 드라이버가 클라이언트 프로그램에 사용되었습니다. 사용하는 다른 드라이버가 있거나 문제가 발생한 경우 askcosmosdbcassandra@microsoft.com으로 이메일을 보내주세요.

예. 일반 구문을 사용하여 복합 파티션 키를 만들 수 있습니다.

아니요. sstableloader는 지원되지 않습니다.

이제 Azure Cosmos DB는 작업 오버헤드 없이 클라우드 환경에 최적화된 환경을 제공합니다. 페어링이 필요할 경우 해당 시나리오에 대한 설명이 포함된 이메일을 askcosmosdbcassandra@microsoft.com으로 보내주세요. 온-프레미스 또는 클라우드 Cassandra 클러스터를 Azure Cosmos DB용 API for Cassandra와 쌍으로 연결하는 데 도움이 되는 제품을 개발 중입니다.

Azure Cosmos DB는 모든 API에서 4시간 간격으로 수행되는 무료 전체 백업을 2회 제공합니다. 따라서 백업 일정을 설정하지 않아도 됩니다.

백업 보존 및 빈도를 직접 관리할 수 있습니다.

백업에서 복원하려면 askcosmosdbcassandra@microsoft.com으로 이메일을 보내거나 지원 사례를 제기합니다. 백업 기능에 대한 정보는 Azure Cosmos DB로 자동 온라인 백업 및 복원 문서에 나와 있습니다.

API for Cassandra는 Azure Cosmos DB의 전역 분산형 플랫폼을 차용합니다. 애플리케이션이 데이터 센터 가동 중지 시간을 견딜 수 있도록 하려면 Azure Portal에서 계정에 하나 이상의 추가 지역을 사용하도록 설정합니다. 자세한 내용은 Azure Cosmos DB의 고가용성을 참조하세요.

계정에 대해 원하는 개수의 지역을 추가하고 장애 조치(Failover) 우선 순위를 지정하여 장애 조치할 수 있는 위치를 제어할 수 있습니다. 데이터베이스를 사용하려면 애플리케이션도 제공해야 합니다. 이렇게 하면 고객에게 가동 중지 시간이 발생하지 않습니다.

아니요. API for Cassandra는 Apache Cassandra와 비슷한 방식으로 동작하는 보조 인덱스를 지원합니다. API는 기본적으로 모든 특성을 인덱싱하지 않습니다.

예, 지원됩니다. 이 기능을 사용하도록 설정하는 방법에 관한 자세한 내용은 로컬 개발 및 테스트에 Azure Cosmos DB 에뮬레이터 사용 문서를 참조하세요.

마이그레이션 옵션에 관해서는 Azure Cosmos DB에서 API for Cassandra 계정으로 데이터 마이그레이션 자습서를 참조하세요.

관련 콘텐츠

• Azure Cosmos DB for Apache Cassandra 계정의 탄력적 크기 조정 시작

다음 단계