NDCS의 전역 활성 테이블
Oracle NoSQL Database Cloud Service는 테이블을 생성하고 여러 지역에 걸쳐 복제하며 지역 복제본 간에 동기화된 데이터를 유지 관리할 수 있는 글로벌 활성 테이블 아키텍처를 지원합니다.
오늘날의 기업은 고객에게 더 빠르고 더 나은 서비스를 제공해야 합니다. 네트워크 대기 시간은 애플리케이션의 성능을 평가하는 데 중요한 매개변수입니다. 네트워크 대기 시간은 데이터 패킷이 네트워크를 통과하는 데 걸리는 최소 시간입니다. 사용자는 어디에서나 빠르고 원활하게 온라인 활동을 완료할 것으로 기대합니다. 이러한 기대를 충족하기 위해 기업은 사용자와 가장 가까운 분산 지역에 애플리케이션과 데이터를 호스팅해야 합니다.
Oracle NoSQL Database Cloud Service는 글로벌 활성 테이블을 통해 이러한 요구사항에 대한 솔루션을 제공합니다. 이 기능을 사용하면 영역에 기록된 응용 프로그램 데이터를 여러 영역에 투명하게 복제할 수 있습니다.
- 로컬 읽기 및 쓰기, 전역 데이터 액세스: 여러 영역에서 전역 활성 테이블의 활성-활성 구성을 사용하면 한 영역의 테이블에 대해 수행된 업데이트가 다른 복제 영역의 테이블 복제본에 자동으로 복제됩니다. 복제된 모든 영역에서 데이터에 액세스할 수 있습니다.
- 성능: Global Active Table을 사용하면 데이터를 로컬에서 읽고 쓸 수 있으며, 10밀리초 미만의 대기 시간을 제공합니다. 대기 시간은 전 세계적으로 분산된 애플리케이션에 대한 로컬 액세스의 특징입니다. 따라서 대규모로 확장된 글로벌 애플리케이션의 성능을 높이고 애플리케이션 요청 대기 시간을 줄일 수 있습니다.
- 설정 및 관리 용이성: Oracle NoSQL Database Cloud Service는 글로벌 활성 테이블을 사용하여 다중 지역 복제를 배포하고 관리하는 복잡성을 제거합니다. 지역별 테이블 복제본 추가는 간단하며 API, Terraform 또는 OCI 콘솔을 사용하여 수행할 수 있습니다.
- 다중 영역 복원력: 전역 활성 테이블도 영역 실패의 드문 경우 내결함성을 사용으로 설정합니다. 단일 영역을 사용할 수 없거나 오프라인 상태가 되면 응용 프로그램 요청을 테이블이 복제된 영역으로 재지정하고 이 테이블에 대해 읽기 및 쓰기를 수행할 수 있습니다.
NDCS에서 글로벌 활성 설정을 선택하는 방법?
전역 활성 테이블 기능을 사용하면 영역에 기록된 응용 프로그램 데이터를 여러 영역에 투명하게 복제할 수 있습니다.
드문 경우지만 단일 영역 failure가 발생해도 유저의 경험에 영향을 주지 않습니다. 예를 들어, 단일 영역이 오프라인, 격리 또는 성능 저하되는 경우 애플리케이션을 다른 영역으로 재지정하고 이전처럼 계속 읽기 및 쓰기를 수행해야 합니다. 즉, 리전이 실패한 경우에도 데이터베이스가 재해 복구를 제공해야 합니다. Oracle NoSQL Database Cloud Service(NDCS)의 글로벌 활성 테이블을 사용하여 활성-활성 구성을 통해 재해 복구를 제공하거나 로컬 데이터 액세스를 통해 짧은 대기 시간을 달성하기 위해 여러 리전에서 데이터를 적극적으로 복제할 수 있습니다.
인기있는 웹 사이트에서 쇼핑하는 여행 사용자의 요구를 고려하십시오. 그들은 같은 날에 세계의 다른 지역에서 같은 쇼핑 웹 사이트에 액세스 할 수 있습니다. 사용자는 어디에 있든 최소한의 대기 시간과 원활한 상호 작용을 경험할 수 있어야 합니다.
NDCS의 전역 활성 테이블 기능은 위에서 설명한 두 시나리오에 대한 해결책을 제공합니다. 두 시나리오를 각각 살펴보고 Global Active Table이 고가용성, 짧은 대기 시간 및 재해 복구를 제공하는 최상의 솔루션이 될 수 있는 방법을 이해해 보겠습니다.
첫 번째 시나리오에서는 회사에서 피닉스(미국-서부), 프랑크푸르트(독일) 및 도쿄(일본)의 NDCS를 사용하고 전 세계 여러 지역에서 쇼핑하는 고객의 쇼핑 정보를 저장하는 ShoppingCart라는 테이블이 있다고 가정합니다. 이 예에서 귀사는 지리적으로 가장 가까운 데이터 센터를 통해 고객에게 서비스를 제공하고 있습니다. 이러한 설정에는 Oracle NoSQL Database Cloud Service를 사용할 수 있는 여러 지리적 위치가 포함됩니다. 지리적으로 분산된 리전이 두 개 이상 있고 각 리전에서 사용할 수 있는 NoSQL Database Cloud 서비스가 있는 구조를 전역 활성 테이블 구조라고 합니다. ShoppingCart 테이블은 전역 활성 테이블이며 여러 영역에서 복제됩니다.
활성-활성 구성에서는 여러 영역에서 NDCS를 사용할 수 있으며 모든 영역의 데이터가 동기화됩니다. 영역이 실패하면 다른 복제본 영역에 있는 전역 활성 테이블은 평소와 같이 계속 작동하며 실패한 영역의 영향을 받지 않습니다. 실패한 영역이 돌아오면 해당 지역 테이블 복제본이 다른 지역과 동기화됩니다. 전역 활성 테이블은 영역이 작동 중지되었을 때 응용 프로그램이 다른 복제본에 연결되어 있다는 점에서 재해 복구를 제공합니다.
두 번째 시나리오에서는 Phoenix의 사용자가 온라인 쇼핑몰에 있고 쇼핑 카트에 휴대폰을 추가한다고 가정합니다. 서해안 NDCS 지역은 이 세션을 제공하며, 사용자는 해당 지역의 로컬 데이터 저장소에서 최소 읽기 및 쓰기 요청 대기 시간을 경험합니다. 이 사용자는 13 시간 후에 독일에 비행기를 타고 호텔에 도착하고 Wi-Fi 네트워크에 연결하고 모바일 회사의 온라인 상점에 가서 더 매력적으로 보이는 다른 전화 모델이 있음을 알게됩니다. 따라서 사용자는 이 새로운 전화 모델로 쇼핑 카트를 업데이트하기로 결정하고 모바일 전자 상거래 상점을 계속 탐색합니다. 가장 근접한 데이터 저장소인 프랑크푸르트의 지역 데이터 저장소는 이 세션을 제공하며 사용자에게 미국과 동일한 짧은 대기 시간의 읽기 및 쓰기 환경을 제공합니다. 그런 다음 사용자는 일본으로 여행하고 최신 모바일 모델에 대한 자세한 정보를 얻기 위해 현지 모바일 상점을 방문하기로 결정합니다. 그런 다음 사용자가 모바일 상점에 있는 최신 전화 모델로 쇼핑 카트를 갱신합니다. NoSQL Database Cloud Service는 피닉스(Phoenix), 독일(독일) 및 일본(일본)의 세 지역에서 사용할 수 있으며, 사용자가 쇼핑 카트를 업데이트하거나 모바일 전자상거래 스토어를 탐색할 때마다 개인화된 검색 결과 및 사용자와 가장 가까운 지역으로부터 데이터를 가져올 수 있습니다. 이러한 종류의 로컬 처리는 대기 시간이 가장 짧고 성능이 가장 뛰어나며 광역 네트워크 액세스를 제거합니다.
기본 개념
Global Active Table에 사용되는 용어:
- 지역: Oracle Cloud Infrastructure(OCI) 지역. 고객이 애플리케이션을 배포할 수 있는 단일 지역화된 지리적 영역입니다.
- 발신자 영역: 테이블 갱신이 다른 영역으로 복제되는 영역입니다.
- 수신자 영역: 다른 영역에서 테이블 갱신을 수신하는 영역입니다.
- 싱글톤 테이블: 지역적으로 복제되지 않는 테이블입니다.
- 영역 테이블 복제본: 다른 영역에서 생성된 테이블의 복제본입니다.
- Global Active Table: 하나 이상의 지역 테이블 복제본이 있는 테이블입니다.
Global Active Table 생성 및 관리를 위한 기본 규칙:
- 싱글톤 테이블에는 JSON 열이 하나 이상 있어야 합니다.
- 테이블의 스키마 상태는 FROZEN이어야 합니다.
- 수신자 영역에는 동일한 이름의 테이블이 존재하지 않아야 합니다.
- 수신자 영역에는 (발신자 영역의 이름과 동일한 이름을 가진) 구획이 존재해야 합니다.
- 테이블을 삭제하기 전에 테이블의 모든 지역 테이블 복제본을 제거해야 합니다.
주:
NDCS에서는 지역별 테이블 복제가 백그라운드에서 비동기적으로 수행됩니다.전역 활성 테이블에서 하위 테이블을 생성할 수 있습니다. 글로벌 활성 테이블의 하위 테이블은 싱글톤 테이블 또는 글로벌 활성 테이블일 수 있습니다. 자식 테이블을 전역 활성 테이블로 만들려면 자식 테이블의 스키마를 고정하고 지역 복제본을 추가해야 합니다. 상위 테이블의 지역별 복제본 중 하나를 선택할 수 있습니다.
전역 활성 테이블 워크플로우
Global Active Table에서 복제되는 항목은 무엇입니까?
- 테이블 정의/스키마
- 테이블의 인덱스 - 보조 인덱스의 개수 및 정의
- 테이블의 데이터.
- 읽기 용량 및 쓰기 용량 - 기본적으로 지역 복제본의 읽기 제한은 전역 활성 테이블의 다른 지역 복제본의 읽기 제한과 동일합니다. 그러나 읽기 작업은 순전히 로컬이므로 선택적으로 각 영역의 고유 읽기 제한을 설정할 수 있습니다. 기본적으로 지역 복제본의 쓰기 제한은 전역 활성 테이블의 다른 지역 복제본의 쓰기 제한과 동일합니다. 그러나 쓰기 제한은 각 영역에서 다른 값으로 설정할 수 있습니다.
- 스토리지 용량 - Global Active 테이블의 모든 지역 복제본은 동일한 테이블 데이터를 저장하므로 지역 복제본의 스토리지 제한은 Global Active 테이블의 다른 모든 지역 복제본에 복사됩니다.
- 테이블의 기본 TTL(테이블 보관 시간)
지역별 테이블 복제본 추가
주:
지역 테이블 복제본을 추가하면 수신자 영역의 테이블이 발신자 영역의 테이블과 동일한 테이블 이름을 가진 동일한 구획에 배치됩니다. 전역 활성 테이블 수명 동안 언제든지 다른 구획으로 이동할 수 있습니다.지역별 테이블 복제본에 대한 용량(읽기 단위, 쓰기 단위 및 스토리지)
테이블의 지역 복제본을 추가하면 읽기 용량, 쓰기 용량 및 저장 용량 필드가 자동으로 발신자 영역에 있는 테이블의 해당 값으로 기본 설정됩니다. 그러나 수신기 영역에서 테이블의 읽기 용량 및 쓰기 용량 값을 편집하고 변경할 수 있습니다. 테이블의 스토리지 용량을 변경할 수 없습니다. 수신기 영역의 테이블에는 발신자 영역의 테이블과 동일한 저장 용량이 있습니다. Global Active Table의 용량 모드는 요청 시 또는 프로비저닝(Provisioning)될 수 있습니다. Global Active 테이블이 생성된 후 지역별 복제본의 용량 모드를 변경할 수도 있습니다. 용량 모드의 변경은 해당 지역 복제본에 대한 로컬이며 Global Active 테이블의 다른 지역 복제본에는 영향을 주지 않습니다.
지역 테이블 복제본의 레코드 TTL
테이블 보관 시간(TTL)은 데이터가 테이블에 보관할 수 있는 시간(시간 또는 일)으로 표현됩니다. Oracle NoSQL Database Cloud Service를 통해 개발자는 테이블 행에 만료 시간을 설정하여 행이 자동으로 만료되고 더 이상 사용할 수 없게 됩니다. 지정된 기간이 지나면 행이 자동으로 만료되어 더 이상 사용할 수 없습니다. 지역 테이블 복제본의 TTL은 발신자 영역의 테이블 TTL과 동일한 값입니다. 행이 다른 영역에 복제되면 만료 시간이 절대 시간 기록으로 복제됩니다. 따라서 이 행은 복제된 시간에 관계없이 동시에 만료됩니다.
지역 테이블 복제본이 생성되면 발신자 지역 테이블의 데이터로 초기화됩니다. 이 테이블 데이터 초기화 중 TTL 값에 도달하면 이러한 행이 만료되고 읽기 작업에 이러한 레코드가 표시되지 않습니다.
지역별 테이블 복제본이 생성된 후의 DDL 작업 범위는 다음과 같습니다.
- 인덱스 추가
- 인덱스 삭제
- 테이블의 스토리지 용량 변경
- 테이블 TTL 변경
- 읽기 단위 변경
- 쓰기 단위 변경
- 용량 모드를 온디맨드에서 프로비저닝됨으로 또는 그 반대로 변경
전역 활성 테이블에 대한 데이터 모델링 고려 사항
테이블의 스키마를 고정해야 하는 이유는 무엇입니까?
Global Active Table 구성에서는 NDCS의 테이블이 여러 지역에 배치되어 있으며 모든 지역에서 동시에 읽기 및 쓰기 요청을 제공하고 있습니다. NDCS에 접속하는 애플리케이션은 가장 가까운 복제 영역에 접속하도록 설계되어야 합니다. 테이블의 기본 키, 샤드 키 및 데이터는 복제 영역 간에 동일해야 합니다. 이 세 가지는 애플리케이션이 테이블을 사용하는 방법과 질의 실행 방법에 대한 본질적인 부분이기 때문입니다. Global Active 테이블에서는 테이블 레코드가 여러 영역의 테이블에 동시에 기록될 수 있으므로 테이블의 스키마에 대한 합의에 도달해야 합니다. 이렇게 하려면 스키마가 변경되지 않도록 하여 모든 영역이 테이블의 스키마에 대해 즉시 합의되도록 할 수 있습니다. 단순성, 성능 및 예측 가능성을 위해 Oracle NoSQL Cloud Service를 사용하려면 지역 복제에 참여하는 테이블에 대해 스키마를 고정해야 합니다. 따라서 싱글톤 테이블을 Global Active Table로 변환하기 전에 테이블 스키마를 고정해야 하며 추가 스키마 변경이 허용되지 않습니다. 지역 복제본을 생성한 후 전역 활성 테이블의 스키마를 변경해야 하는 경우 먼저 모든 지역 복제본을 삭제하고 테이블의 스키마를 변경한 다음 지역 복제본을 다시 추가해야 합니다. Oracle NoSQL 클라우드 서비스는 모든 지역 복제본을 발신자 지역의 최신 데이터로 다시 채웁니다.
스키마를 고정할 때 테이블에 JSON 열이 하나 이상 필요한 이유는 무엇입니까?
지역별 테이블 복제본에서 스키마 변경을 조정하기는 어렵고 잠재적인 오류 사례로 이어집니다. JSON 열을 제공하면 스키마의 유연성이 향상되고 스키마 변경이 필요하지 않습니다.
전역 활성 테이블에서 ID 정의
-
지역 테이블 복제본의 레코드 ID는 테이블의 모든 지역 복제본에서 고유해야 합니다. 테이블의 각 레코드를 식별하는 일반 키(전역적으로 고유한 식별자)는 모든 지역 테이블 복제본에서 고유성을 보장할 수 있는 경우에만 글로벌 활성 테이블에서 ID로 사용할 수 있습니다.
- 전역 활성 테이블에서 시스템 생성 ID를 사용하는 동안 UUID를 사용해야 합니다. 대부분의 경우 ID 열은 지역 테이블 복제본 전체에서 고유하지 않으므로 사용하지 않아야 합니다.
정책 및 사용자 권한
테이블의 IAM 정책은 발신자 영역에만 적용됩니다.
사용자가 싱글톤 테이블 또는 전역 활성 테이블의 복제본을 추가하면 수신기 영역에 정책 또는 사용자 권한이 추가되지 않습니다. 복제본을 생성하고 관리하려는 소스 영역의 사용자도 수신기 영역에서 필요한 권한을 가져야 합니다. 그렇지 않으면 사용자가 지역 테이블 복제본을 추가할 때 오류가 발생합니다.
지역 테이블 복제본이 생성되면 발신자 영역에서 수신자 영역으로 데이터 수정을 복제할 때 사용자 권한이 필요하지 않습니다. 즉, 사용자 권한에 관계없이 한 복제본 테이블의 데이터 변경 사항이 다른 모든 테이블 복제본에 복제됩니다. 지역별 테이블 복제본을 만들고 관리하는 데 필요한 권한이 아래에 나열되어 있습니다.
복제본 추가:
테이블의 복제본을 관리하려는 사용자는 발신자 영역 및 모든 기존 수신자 영역에 NOSQL_TABLE_ALTER 권한이 있어야 합니다. 새 복제본을 만들려는 사용자는 수신기 영역(복제본을 만들어야 하는 위치)에 NOSQL_TABLE_CREATE permission이 있어야 합니다. 지역 테이블 복제본을 생성할 때 발신자 영역에 있는 테이블의 기존 읽기 및 쓰기 권한이 수신자 영역에 생성되지 않습니다. 수신기 영역에 새 복제본을 만들려는 사용자는 자신이 만든 모든 지역 테이블 복제본에 대해 테이블 읽기 및 쓰기 권한을 만듭니다.
복제본 삭제:
테이블의 복제본을 관리하려는 사용자는 발신자 영역 및 모든 기존 수신자 영역에 NOSQL_TABLE_ALTER 권한이 있어야 합니다. 복제본을 삭제하려는 사용자는 수신기 영역(복제본을 삭제해야 하는 경우)에서 NOSQL_TABLE_DROP permission을 보유해야 합니다.
인덱스 생성::
지역별 테이블 복제본에서 인덱스를 만들려는 사용자에게는 NOSQL_INDEX_CREATE 권한이 있어야 합니다.
인덱스 삭제:
지역별 테이블 복제본에서 인덱스를 삭제하려는 사용자에게는 NOSQL_INDEX_DROP 권한이 있어야 합니다.
테이블 제한/TTL/ 갱신:
테이블의 복제본을 관리하려는 사용자는 모든 지역별 테이블 복제본에서 NOSQL_TABLE_ALTER 권한을 가지고 있어야 합니다.
읽기, 쓰기 및 ACID 트랜잭션
Global Active Table을 생성한 후에는 기존 데이터 액세스 API나 DML 문을 사용하여 테이블에 대해 읽기 또는 쓰기 작업을 수행할 수 있습니다.
최상의 대기 시간을 위해 애플리케이션은 일반적으로 로컬 지역 복제본에서 읽습니다. 로컬 지역 복제본의 데이터에는 다른 지역 테이블 복제본에서 복제된 데이터 업데이트도 포함됩니다. Global Active Table에서 쓰기 작업(INSERT, UPDATE 또는 DELETE)을 실행할 때마다 여러 영역에 비동기적으로 변경 사항이 복제됩니다. 즉, 발신자 영역에 행을 작성할 때 복제본 영역이 업데이트되기를 기다리지 않고 발신자 영역에서 쓰기 작업이 완전히 실행됩니다. 여러 영역이 동일한 기본 키로 행을 갱신하는 경우 최종으로 간주되는 영역의 갱신을 결정하는 규칙이 적용됩니다. 이러한 모든 경우에 이 내장된 충돌 해결 규칙으로 인해 최신 시간 기록이 포함된 업데이트가 성공하고 데이터베이스에 커밋됩니다. 이 규칙은 여러 영역에서 동시에 TTL 값을 업데이트하는 경우에도 적용됩니다.
ACID 트랜잭션은 지역에 로컬입니다. 트랜잭션 커밋 시에는 쓰기가 발생한 영역에서만 원자, 일관성, 격리 및 지속성이 보장됩니다. 지역 테이블 복제본의 일관성 모델 의미는 복제되지 않은 테이블의 의미와 동일합니다. 지역별 테이블 복제본의 일관성은 절대적이지 않습니다. 절대 일관성은 읽기 작업을 수행하는 단일 영역에 로컬입니다. 발신자 영역에서 수신자 영역으로 복제되는 데이터에 대한 읽기는 항상 일관됩니다.
보낸 사람 영역의 쓰기는 시간 지연 내의 모든 수신자 영역에서 복제됩니다. 여러 영역에서 변경 사항을 복제하기 위한 이 시간 지연에는 발신자 영역의 지역 테이블 복제본에서 데이터를 수신하는 데 걸린 시간과 수신자 영역에서 쓰기 작업을 완료하는 데 걸린 시간이 포함됩니다. 결국 수신자 영역은 발신자 영역에서 업데이트를 가져오고 수신자 영역은 발신자 영역에서 발생한 트랜잭션 업데이트를 놓치지 않습니다. 모든 지역 테이블 복제본은 결국 쓰기를 수신하고 내구성을 갖게 됩니다.
복제본 지연 개요
Global Active Table에서 쓰기 작업(INSERT, UPDATE 또는 DELETE)을 실행할 때마다 여러 영역에 비동기적으로 변경 사항이 복제됩니다.
즉, 발신자 영역에 행을 작성할 때 복제본 영역이 업데이트되기를 기다리지 않고 발신자 영역에서 쓰기 작업이 완전히 실행됩니다. 네트워크 대기 시간은 수신기 영역에 대한 변경사항을 복제하는 데 시간 지연을 생성합니다. 여러 영역에서 변경 사항을 복제하는 대기 시간에는 복제본에서 쓰기를 수신하여 수신자 영역에 적용하는 데 걸리는 시간이 포함됩니다. 발신자 영역에 테이블에 대한 응용 프로그램 쓰기가 없는 경우 서비스는 핑 방식을 사용하여 지연의 근사값을 계산하며 지연 통계는 수신자 영역에서 계속 사용할 수 있습니다.
복제 지연 측정항목에 대한 자세한 내용은 Details on Replica Lag를 참조하십시오.
전역 활성 테이블 생성 개요
글로벌 활성 테이블을 생성하는 프로세스는 싱글톤 테이블을 생성한 다음 글로벌 활성 테이블로 변환하는 작업부터 시작합니다.
- 싱글톤 테이블을 생성하고 한 열이 JSON인지 확인합니다.
- 테이블의 스키마 상태를 Mutable에서 Frozen으로 변경합니다.
- 테이블의 지역 복제본을 추가할 영역을 결정합니다. 지역 복제본을 추가하는 동안 읽기 용량, 쓰기 용량 및 스토리지 용량 필드가 자동으로 발신자 영역의 해당 값으로 채워집니다. 테이블의 읽기 용량 및 쓰기 용량을 변경할 수 있습니다.
- 클라우드 서비스는 수신기 영역에 테이블을 생성합니다. 소스 영역의 테이블에 데이터가 있는 경우 발신자 영역에서 수신자 영역으로 데이터 복사를 시작합니다. 데이터가 발신자 영역에서 수신자 영역으로 복사되면 초기화 백분율이 0에서 100으로 증가합니다. 아래와 같이 OCI 콘솔의 테이블 정보 아래에서 초기화 백분율 값을 볼 수 있습니다. 초기화 프로세스가 완료될 때까지 새 지역 테이블 복제본에서 DML 작업이 허용되지 않습니다.
