고가용성, 짧은 대기 시간 또는 둘 다 복제를 사용하는 분산 데이터베이스는 PACELC 정리에 정의된 대로 읽기 일관성, 가용성, 대기 시간 및 처리량의 균형을 유지해야 합니다. 강력한 일관성 모델의 선형성은 데이터 프로그래밍 기능의 표준입니다. 그러나 데이터가 먼 거리에서 복제 및 커밋되어야 하므로 쓰기 대기 시간이 증가합니다. 또한 강력한 일관성은 데이터가 모든 지역에서 복제 및 커밋할 수 없으므로 실패 시 가용성을 줄입니다. 최종 일관성은 더 높은 가용성과 더 나은 성능을 제공하지만 모든 지역에서 데이터가 일관되지 않을 수 있으므로 애플리케이션을 프로그래밍하기가 더 어렵습니다.
현재 시장에 배포된 대부분의 NoSQL 데이터베이스는 강력하고 최종적인 일관성만 제공합니다. Azure Cosmos DB는 잘 정의된 5가지 수준을 제공합니다. 해당 수준은 가장 강력한 수준부터 가장 약한 수준 순으로 다음과 같습니다.
기본 일관성 수준에 대한 자세한 내용은 기본 일관성 수준 구성 또는 기본 일관성 수준 재정의를 참조하세요.
각 수준은 가용성과 성능의 균형을 유지합니다. 다음 이미지는 일관성 수준을 스펙트럼으로 보여 줍니다.
일관성 수준 및 Azure Cosmos DB API
Azure Cosmos DB는 MongoDB, Apache Cassandra, Apache Gremlin 및 Azure Table Storage를 비롯한 인기 있는 데이터베이스에 대해 유선 프로토콜 호환 API를 지원합니다. Gremlin 또는 Table용 API의 경우 Azure Cosmos DB는 계정에 구성된 기본 일관성 수준을 사용합니다. 일관성 수준 매핑에 대한 자세한 내용은 Apache Cassandra에 대한 Cassandra 일관성 매핑 용 API 및 MongoDB용 MongoDB 일관성 매핑용 API 를 참조하세요.
읽기 일관성 범위
읽기 일관성은 논리 파티션 내의 단일 읽기 작업에 적용됩니다. 원격 클라이언트, 저장 프로시저 또는 트리거는 읽기 작업을 실행할 수 있습니다.
기본 일관성 수준 구성
언제든지 Azure Cosmos DB 계정에서 기본 일관성 수준을 구성합니다. 계정에 구성된 기본 일관성 수준은 해당 계정의 모든 Azure Cosmos DB 데이터베이스 및 컨테이너에 적용됩니다. 컨테이너 또는 데이터베이스에 대해 실행된 모든 읽기 및 쿼리는 기본적으로 지정된 일관성 수준을 사용합니다. 계정 수준 일관성을 변경하는 경우 애플리케이션을 다시 배포하고 이러한 변경 내용을 적용하는 데 필요한 코드를 수정합니다. 기본 일관성 수준을 구성하는 방법에 대해 자세히 알아봅니다. 특정 요청에 대한 기본 일관성 수준을 재정의할 수도 있습니다. 기본 일관성 수준 재정의 문서에서 자세히 알아보세요.
팁
기본 일관성 수준을 재정의하는 것은 SDK 클라이언트 내의 읽기에만 적용됩니다. 기본적으로 강력한 일관성을 위해 구성된 계정은 여전히 데이터를 기록하여 계정의 모든 지역에 동기적으로 복제합니다. SDK 클라이언트 인스턴스 또는 요청이 세션 또는 약한 일관성으로 이 일관성을 재정의하면 단일 복제본을 사용하여 읽기가 수행됩니다. 자세한 내용은 일관성 수준 및 처리량을 참조하세요.
Important
애플리케이션을 다시 시작하여 기본 일관성 수준을 변경한 후 SDK 인스턴스를 다시 만듭니다. 이 단계에서는 SDK에서 새 기본 일관성 수준을 사용합니다.
일관성 수준과 연결된 보장
Azure Cosmos DB는 100개% 읽기 요청이 선택한 일관성 수준에 대한 일관성 보장을 충족하는지 보장합니다. TLA - 임시 작업 논리 - 사양 언어를 사용하는 Azure Cosmos DB의 5가지 일관성 수준에 대한 정확한 정의는 azure/azure-cosmos-tla GitHub 리포지토리에서 제공됩니다.
5가지 일관성 수준의 의미 체계는 다음 섹션에 설명되어 있습니다.
강력한 일관성
강력한 일관성은 선형화 가능성 보장을 제공합니다. 선형성은 요청을 동시에 제공하는 것을 의미합니다. 읽기를 통해 항목의 최신 커밋된 버전 반환이 보장됩니다. 클라이언트는 커밋되지 않은 쓰기 또는 부분 쓰기를 볼 수 없습니다. 사용자는 항상 최신 커밋 쓰기의 읽기가 보장됩니다.
다음 그래픽은 음원과의 강력한 일관성을 보여 줍니다. "미국 서부 2" 지역에 데이터를 쓴 후 다른 지역의 데이터를 읽으면 최신 값을 얻게 됩니다.
동적 Quorum
정상적인 상황에서는 일관성이 강한 계정의 경우 모든 지역에서 레코드 복제를 승인할 때 쓰기가 커밋된 것으로 간주됩니다. 계정에 3개 이상의 지역이 있는 경우 일부 지역이 느리거나 응답하지 않는 경우 시스템에서 쿼럼에 필요한 지역 수를 줄일 수 있습니다. 이렇게 하면 일부 지역에 문제가 있더라도 강력한 일관성을 유지할 수 있습니다. 이때 강력한 일관성을 유지하기 위해 응답하지 않는 지역이 지역 Quorum 집합에서 제거됩니다. 다른 지역과 일치하고 예상대로 수행될 때만 다시 추가됩니다. 잠재적으로 쿼럼 집합에서 제거할 수 있는 지역 수는 총 지역 수에 따라 달라집니다. 예를 들어 3개 또는 4개의 지역 계정에서 대부분은 각각 2개 또는 3개의 지역이므로 두 경우 모두 하나의 지역만 제거할 수 있습니다. 5개 지역 계정의 경우 대부분은 3개이므로 응답하지 않는 지역을 최대 2개까지 제거할 수 있습니다. 이 기능은 "동적 쿼럼"으로 알려져 있으며 3개 이상의 지역이 있는 계정에 대한 쓰기 가용성 및 복제 대기 시간을 모두 향상시킬 수 있습니다.
참고 항목
동적 쿼럼의 일부로 쿼럼 집합에서 지역이 제거되면 해당 지역은 쿼럼으로 읽을 때까지 더 이상 읽기를 제공할 수 없습니다.
제한된 부실 일관성
둘 이상의 지역이 있는 단일 지역 쓰기 계정의 경우 데이터가 주 지역에서 모든 보조(읽기 전용) 지역으로 복제됩니다. 둘 이상의 지역이 있는 다중 지역 쓰기 계정의 경우 데이터가 원래 기록된 지역에서 다른 모든 쓰기 가능 지역으로 복제됩니다. 두 시나리오 모두 일반적이지는 않지만 때때로 한 지역에서 다른 지역으로의 복제 지연이 있을 수 있습니다.
제한된 부실 일관성에서 두 지역 간의 데이터 지연은 항상 지정된 양보다 작습니다. 양은 항목의 "K" 버전(즉, "업데이트") 또는 "T" 시간 간격(둘 중 먼저 도달하는 간격)만큼일 수 있습니다. 즉, 제한된 부실을 선택하면 모든 지역에서 데이터의 최대 "부실"을 두 가지 방식으로 설정할 수 있습니다.
- 항목의 버전(K) 수
- 읽기가 쓰기보다 뒤처질 수 있는 시간 간격(T)
제한된 부실은 두 개 이상의 지역이 있는 단일 지역 쓰기 계정에 주로 유용합니다. 영역의 데이터 지연(실제 파티션별로 결정됨)이 구성된 부실 값을 초과하는 경우 부실이 구성된 상한 이내로 다시 들어올 때까지 해당 파티션에 대한 쓰기가 제한됩니다.
단일 지역 계정의 경우 제한된 부실은 세션 및 최종 일관성과 동일한 쓰기 일관성 보장을 제공합니다. 제한된 부실을 사용하면 데이터가 단일 지역의 로컬 과반수(4개의 복제본 세트 중 3개의 복제본)에 복제됩니다.
Important
제한된 부실 일관성을 사용하면 지역 내가 아닌 지역 간에만 부실 검사가 수행됩니다. 지정된 지역 내에서 데이터는 일관성 수준에 관계없이 항상 로컬 대다수(4개의 복제본 집합에 있는 3개의 복제본)에 복제됩니다.
제한된 부실 사용 시 읽기는 해당 지역에서 사용 가능한 두 복제본에서 읽어 해당 지역에서 사용할 수 있는 최신 데이터를 반환합니다. 지역 내의 쓰기는 항상 로컬 과반수(복제본 4개 중 3개)에 복제되므로 두 복제본을 참조하면 해당 지역에서 사용할 수 있는 가장 업데이트된 데이터가 반환됩니다.
Important
제한된 부실 일관성을 사용하면 비초년 지역에서 읽는 경우 모든 지역의 최신 데이터가 표시되지 않을 수 있습니다. 그러나 허용되는 부실 한도 내에서 항상 해당 지역에서 사용할 수 있는 최신 데이터를 반환합니다.
제한된 부실은 지역 간에 거의 강력한 일관성이 필요한 두 개 이상의 지역이 있는 단일 지역 쓰기 계정을 사용하는 전역적으로 분산된 애플리케이션에 가장 적합합니다. 둘 이상의 지역이 있는 다중 지역 쓰기 계정의 경우 애플리케이션 서버가 호스트되는 지역과 동일한 지역에 읽기 및 쓰기를 전달해야 합니다. 다중 쓰기 계정의 제한된 부실은 안티패턴입니다. 이 수준에는 지역 간의 복제 지연에 대한 종속성이 필요하며, 데이터가 기록된 지역과 동일한 지역에서 데이터를 읽는지 여부는 중요하지 않습니다.
다음 그림은 악보와의 제한된 부실 일관성을 보여 줍니다. "미국 서부 2" 지역에 데이터를 쓴 후 "미국 동부 2" 및 "오스트레일리아 동부" 지역은 구성된 최대 지연 시간 또는 최대 작업을 기준으로 작성된 값을 읽습니다.
세션 일관성
세션 일관성에서는 단일 클라이언트 세션 내의 읽기에서 쓰기 읽기 및 읽기 뒤 쓰기 보장을 적용하도록 합니다. 이 보장은 단일 "기록기" 세션을 가정하거나 여러 기록기에 대한 세션 토큰을 공유합니다.
강력보다 약한 모든 일관성 수준과 마찬가지로, 쓰기는 다른 모든 지역에 대한 비동기 복제를 사용하여 로컬 지역에서 4개의 복제본 세트 중 최소 3개의 복제본에 복제됩니다.
모든 쓰기 작업 후에 클라이언트는 서버에서 업데이트된 세션 토큰을 받습니다. 클라이언트는 토큰을 캐시하고 지정된 지역에서 읽기 작업을 위해 서버로 보냅니다. 읽기 작업이 실행되는 복제본에 지정된 토큰(또는 최신 토큰)에 대한 데이터가 포함된 경우 요청된 데이터가 반환됩니다. 복제본에 해당 세션에 대한 데이터가 없는 경우 클라이언트는 해당 지역의 다른 복제본에 대해 요청을 다시 시도합니다. 필요한 경우 클라이언트는 지정된 세션 토큰에 대한 데이터가 검색될 때까지 사용 가능한 추가 지역에 대해 읽기를 다시 시도합니다.
Important
세션 일관성에서 클라이언트는 세션 토큰을 사용하여 이전 세션에 해당하는 데이터를 절대 읽지 않도록 보장합니다. 클라이언트가 이전 세션 토큰을 사용하지만 데이터베이스에서 최신 데이터를 사용할 수 있는 경우 시스템은 최신 버전을 반환합니다. 오래된 토큰이 있더라도 항상 최신 데이터를 얻을 수 있습니다. 세션 토큰은 최소 버전 장벽으로 사용되지만 데이터베이스에서 검색할 데이터의 특정(기록) 버전으로 사용되지는 않습니다.
Azure Cosmos DB의 세션 토큰은 파티션에 바인딩되어 있으므로 하나의 파티션과만 연결됩니다. 쓰기를 읽을 수 있도록 관련 항목에 대해 마지막으로 생성된 세션 토큰을 사용합니다.
클라이언트가 실제 파티션에 대한 쓰기를 시작하지 않은 경우, 클라이언트 캐시에 세션 토큰이 포함되지 않으며 해당 물리적 파티션에 대한 읽기는 최종 일관성을 사용하는 읽기로 동작합니다. 마찬가지로, 클라이언트가 다시 만들어지면 세션 토큰의 캐시도 다시 만들어집니다. 이 경우에도 읽기 작업은 후속 쓰기 작업이 클라이언트의 세션 토큰 캐시를 다시 빌드할 때까지 최종 일관성과 동일한 동작을 따릅니다.
Important
세션 토큰이 한 클라이언트 인스턴스에서 다른 클라이언트 인스턴스로 전달되는 경우 토큰의 내용을 수정하면 안 됩니다.
세션 일관성은 단일 지역 및 전역적으로 분산된 애플리케이션에 가장 널리 사용되는 일관성 수준입니다. 최종 일관성과 비슷한 쓰기 대기 시간, 가용성 및 읽기 처리량을 제공합니다. 또한 세션 일관성은 사용자의 컨텍스트에서 작동하도록 작성된 애플리케이션의 요구 사항에 맞는 일관성 보장을 제공합니다. 다음 그림은 악보와의 세션 일관성을 보여 줍니다. "미국 동부 2 쓰기 권한자" 및 "미국 서부 2 읽기 권한자"는 동일한 세션(세션 A)을 사용하고 있으므로 동일한 데이터를 동시에 읽을 수 있습니다. "오스트레일리아 동부" 지역은 "세션 B"를 사용하는 반면, 나중에 쓰기와 동일한 순서로 데이터를 받습니다.
일관적인 접두사 일관성
강력보다 약한 모든 일관성 수준과 마찬가지로, 쓰기는 다른 모든 지역에 대한 비동기 복제를 사용하여 로컬 지역에서 4개의 복제본 세트 중 최소 3개의 복제본에 복제됩니다.
일관된 접두사에서 단일 문서 쓰기로 만들어진 업데이트는 최종 일관성을 확인합니다.
트랜잭션 내에서 일괄 처리로 만들어진 업데이트는 커밋된 트랜잭션과 일관되게 반환됩니다. 여러 문서의 트랜잭션 내에서 쓰기 작업은 항상 함께 표시됩니다.
트랜잭션 T1 및 T2 내에서 문서 Doc1 및 문서 Doc2에 대한 두 개의 쓰기 작업이 트랜잭션 방식(전부 또는 전무)으로 수행된다고 가정하겠습니다. 클라이언트가 모든 복제본에서 읽기를 수행하는 경우 사용자는 "Doc1 v1 및 Doc2 v1" 또는 "Doc1 v2 및 Doc2 v2" 또는 복제본이 지연되는 경우 두 문서 모두 표시되지만 동일한 읽기 또는 쿼리 작업에 대해 "Doc1 v1 및 Doc2 v2" 또는 "Doc1 v2 및 Doc2 v1"은 표시되지 않습니다.
다음 그림은 음표와의 일관성 접두사 일관성을 보여 줍니다. 모든 지역에서 읽기는 트랜잭션 쓰기 일괄 처리에서 순서가 잘못된 쓰기를 볼 수 없습니다.
최종 일관성
강력보다 약한 모든 일관성 수준과 마찬가지로, 쓰기는 다른 모든 지역에 대한 비동기 복제를 사용하여 로컬 지역에서 4개의 복제본 세트 중 최소 3개의 복제본에 복제됩니다.
최종 일관성에서 클라이언트는 지정된 지역의 4개 복제본 중 하나에 대해 읽기 요청을 실행합니다. 이 복제본은 지연될 수 있으며 부실하거나 데이터를 반환하지 않을 수 있습니다.
클라이언트가 과거에 읽은 값보다 오래된 값을 읽을 수 있기 때문에 최종 일관성은 가장 약한 형태의 일관성입니다. 최종 일관성은 애플리케이션에 순서를 보장하지 않아도 되는 경우에 적합합니다. 예를 들어 리트윗, 좋아요 또는 스레드되지 않은 댓글의 수가 있습니다. 다음 그림은 음표와의 최종 일관성을 보여 줍니다.
실제 일관성 보증
실제로 더 강력한 일관성 보장을 얻을 수 있습니다. 새로 고침 및 요청하는 데이터베이스의 상태 순서에 해당하는 읽기 작업에 대한 일관성 보장입니다. 읽기 일관성은 쓰기 및 업데이트 작업의 순서 지정 및 전파에 연결됩니다.
데이터베이스에 쓰기 작업이 없는 경우 최종, 세션 또는 일관된 접두사 일관성 수준이 있는 읽기 작업은 강력한 일관성 수준의 읽기 작업과 동일한 결과를 얻을 수 있습니다.
계정이 강력한 일관성이 아닌 일관성 수준으로 구성된 경우 클라이언트가 워크로드에 대해 강력하고 일관된 읽기를 받을 확률을 확인할 수 있습니다. PBS(확률적으로 제한된 부실) 메트릭을 확인하여 이 확률을 파악합니다. 이 메트릭은 Azure Portal에 노출됩니다. 자세한 내용은 PBS(확률적으로 제한된 부실) 메트릭 모니터링을 참조하세요.
확률적으로 제한된 부실은 최종 일관성이 얼마나 최종적인지를 보여줍니다. 이 메트릭은 Azure Cosmos DB 계정에 현재 구성된 일관성 수준보다 더 강력한 일관성을 얻는 빈도에 대한 인사이트를 제공합니다. 즉, 쓰기 및 읽기 영역의 조합에 대해 일관된 읽기를 얻을 확률(밀리초 단위로 측정)을 볼 수 있습니다.
일관성 수준 및 대기 시간
모든 일관성 수준에 대한 읽기 대기 시간은 99번째 백분위수에서 10밀리초 미만으로 보장됩니다. 50번째 백분위수의 평균 읽기 대기 시간은 일반적으로 4밀리초 이하입니다.
모든 일관성 수준에 대한 쓰기 대기 시간은 99번째 백분위수에서 10밀리초 미만으로 보장됩니다. 50번째 백분위수의 평균 쓰기 대기 시간은 일반적으로 5밀리초 이하입니다. 일관성이 강한 여러 지역에 걸쳐 있는 Azure Cosmos DB 계정은 이 보장의 예외입니다.
쓰기 대기 시간 및 강력한 일관성
둘 이상의 지역에서 강력한 일관성을 사용하여 구성된 Azure Cosmos DB 계정에 대한 쓰기 대기 시간은 가장 먼 두 지역 간 RTT(왕복 시간)의 두 배에 99번째 백분위수 10밀리초를 더한 값과 같습니다. 지역 간 네트워크 RTT가 높으면 강력한 일관성이 계정의 모든 지역에 커밋된 후에만 작업을 완료하기 때문에 Azure Cosmos DB 요청 대기 시간이 증가합니다.
정확한 RTT 대기 시간은 광원 거리 속도 및 Azure 네트워킹 토폴로지에 따라 달라집니다. Azure 네트워킹은 Azure 지역 간 RTT에 대한 대기 시간 SLA(서비스 수준 계약)를 제공하지 않지만 Azure 네트워크 왕복 대기 시간 통계를 게시합니다. Azure Cosmos DB 계정의 경우 Azure Portal에 복제 대기 시간이 표시됩니다. 메트릭 섹션으로 이동하여 일관성 옵션을 선택하여 Azure Portal을 사용합니다. Azure Portal을 사용하여 Azure Cosmos DB 계정과 연결된 다양한 지역 간의 복제 대기 시간을 모니터링할 수 있습니다.
Important
쓰기 대기 시간이 높기 때문에 기본적으로 5,000마일(8,000km)을 초과하는 지역이 있는 계정에 대한 강력한 일관성이 차단됩니다. 이 기능을 사용하도록 설정하려면 지원에 문의하세요.
일관성 수준 및 처리량
강력하고 제한된 부실의 경우 일관성을 보장하기 위해 4개 복제본 집합(소수 쿼럼)의 두 복제본에 대해 읽기가 수행됩니다. 세션, 일관된 접두사 및 최종 일관성은 단일 복제본 읽기를 사용합니다. 따라서 동일한 수의 요청 단위에 대해 강력하고 제한된 부실에 대한 읽기 처리량은 다른 일관성 수준의 절반입니다.
삽입, 바꾸기, 업서트 또는 삭제와 같은 지정된 유형의 쓰기 작업의 경우 요청 단위에 대한 쓰기 처리량은 모든 일관성 수준에서 동일합니다. 강력한 일관성을 위해서는 모든 지역(전역 대다수)에서 변경 내용을 커밋해야 하며, 다른 모든 일관성 수준에서는 로컬 대다수(4개 복제본 집합의 복제본 3개)가 사용됩니다.
| 일관성 수준 | 쿼럼 읽기 | 쿼럼 쓰기 |
|---|---|---|
| 강력 | 로컬 소수 | 전역 과반수 |
| 제한된 부실 | 로컬 소수 | 로컬 과반수 |
| 세션 | 단일 복제본(세션 토큰 사용) | 로컬 과반수 |
| 일관적인 접두사 | 단일 복제본 | 로컬 과반수 |
| 최종 | 단일 복제본 | 로컬 과반수 |
참고 항목
로컬 소수 읽기에 대한 읽기의 RU 비용은 강력한 제한된 부실 일관성 수준에 대한 일관성을 보장하기 위해 두 개의 복제본에서 읽기가 수행되기 때문에 약한 일관성 수준의 두 배입니다.
일관성 수준 및 데이터 내구성
전역적으로 분산된 데이터베이스 환경에서 일관성 수준은 지역 전체 가동 중단 시 데이터 내구성에 직접적인 영향을 줍니다. 비즈니스 연속성 계획을 개발할 때 애플리케이션이 중단 이벤트에서 복구하는 동안 손실을 허용할 수 있는 최근 데이터 업데이트의 최대 기간을 이해합니다. 손실될 수 있는 업데이트 기간을 RPO(복구 지점 목표)라고 합니다.
이 표에서는 지역 전체 가동 중단 시 일관성 모델과 데이터 내구성 간의 관계를 보여 줍니다.
| Regions | 복제 모드 | 일관성 수준 | RPO |
|---|---|---|---|
| 1 | 단일 또는 여러 쓰기 지역 | 일관성 수준 | < 240분 |
| >1 | 단일 쓰기 지역 | 세션, 일관된 접두사, 최종 | < 15분 |
| >1 | 단일 쓰기 지역 | 제한된 부실 | K & T |
| >1 | 단일 쓰기 지역 | 강력 | 0 |
| >1 | 다중 쓰기 지역 | 세션, 일관된 접두사, 최종 | < 15분 |
| >1 | 다중 쓰기 지역 | 제한된 부실 | K & T |
K = 항목의 K 버전(업데이트) 수입니다.
T = 마지막 업데이트 이후의 시간 간격 T 입니다.
단일 지역 계정의 경우 K 및 T 의 최소값은 10개의 쓰기 작업 또는 5초입니다. 다중 지역 계정의 경우 K 및 T 의 최소값은 100,000개의 쓰기 작업 또는 300초입니다. 이 값은 제한된 부실을 사용하는 경우 데이터에 대한 최소 RPO(복구 지점 목표)를 정의합니다.
강력한 일관성 및 다중 쓰기 지역
여러 쓰기 지역이 있는 Azure Cosmos DB 계정은 분산 시스템이 RPO(복구 지점 목표)와 RTO(복구 시간 목표)를 0으로 제공할 수 없으므로 강력한 일관성을 사용할 수 없습니다. 또한 여러 쓰기 지역과의 강력한 일관성은 쓰기를 복제하고 계정의 모든 지역에 커밋해야 하므로 쓰기 대기 시간을 향상하지 않습니다. 이 설정을 사용하면 단일 쓰기 지역 계정과 동일한 쓰기 대기 시간이 발생합니다.
추가 정보
일관성 개념에 대해 자세히 알아보려면 다음 문서를 참조하세요.
- Azure Cosmos DB에서 제공하는 5가지 일관성 수준에 대한 높은 수준의 TLA⁺ 사양
- 더그 테리에 의해 야구 (비디오)를 통해 설명 복제 된 데이터 일관성
- Doug Terry가 야구(백서)를 통해 설명한 복제된 데이터 일관성
- 약하게 일관된 복제 데이터에 대한 세션 보장
- 최신 분산 데이터베이스 시스템 디자인의 일관성 절충: CAP는 스토리의 일부일 뿐입니다.
- 실용적인 부분 쿼럼에 대한 확률적 제한된 부실(PBS)
- 최종적으로 일관성 - 다시 검토됨
관련 콘텐츠
- 기본 일관성 수준 구성
- 기본 일관성 수준 재정의
- Azure Cosmos DB SLA에 대해 자세히 알아봅니다.