이 문서는 Bigtable에서 Datastore로 사용할 기존 애플리케이션을 마이그레이션하거나 새로운 애플리케이션을 설계하려는 소프트웨어 개발자와 데이터베이스 관리자를 대상으로 합니다. 이 문서에서는 Bigtable 사용 시 Apache Cassandra에 관한 지식을 적용합니다.
Bigtable 및 Cassandra는 분산 데이터베이스입니다. 다차원적인 키-값 저장소를 구현하며, 이를 통해 수만에 이르는 초당 쿼리 수 (QPS), 페타바이트 규모의 데이터까지 확장되는 스토리지, 노드 장애에 대한 내결함성을 지원할 수 있습니다.
이러한 데이터베이스의 특성 세트는 상위 수준에서 비슷하지만, 기본적인 아키텍처 및 상호작용 세부정보는 여러 가지 면에서 다르므로 잘 숙지해야 합니다. 이 문서에서는 두 데이터베이스 시스템의 유사점과 차이점을 설명합니다.
Bigtable이 Cassandra 워크로드에 적합한 대상인 경우
Cassandra 워크로드에 가장 적합한 Google Cloud 서비스는 이전 목표와 이전 후 필요한 Cassandra 기능에 따라 다릅니다.
Bigtable은 처리량과 지연 시간이 읽기만큼 쓰기에도 중요한 경우에 최적입니다. Bigtable의 최종 일관성, 빠른 로컬 쓰기, 맞춤 타임스탬프 사용 기능, 유연한 스키마 (예: 업데이트 가능한 컬렉션 유형), 다양한 클러스터 토폴로지를 통해 Bigtable은 진화하는 애플리케이션을 지원하고 비용 효율적으로 지연 시간을 줄일 수 있습니다.
코드를 변경하지 않고 애플리케이션을 마이그레이션하려면 GKE에서 Cassandra를 직접 관리하거나 DataStax 또는 ScyllaDB와 같은 Google Cloud 파트너를 사용하면 됩니다. 애플리케이션에 읽기 작업이 많고 관계형 데이터베이스 기능과 strong consistency를 얻기 위해 코드를 리팩터링할 의향이 있다면 Spanner를 고려해 보세요.
이 문서에서는 Cassandra 워크로드의 마이그레이션 대상으로 Bigtable을 선택하는 경우 애플리케이션 리팩터링 시 고려해야 할 사항에 관한 도움말을 제공합니다.
이 문서 사용 방법
문서를 처음부터 끝까지 다 읽지 않아도 됩니다. 이 문서에서는 두 데이터베이스를 비교하지만 사용 사례 또는 관심분야에 해당하는 주제에 집중할 수도 있습니다.
두 가지 성숙한 데이터베이스를 비교하는 것은 간단한 작업이 아닙니다. 이를 위해 이 문서에서는 다음 작업을 수행합니다.
- 두 데이터베이스 간에 서로 다른 용어를 비교합니다.
- 두 데이터베이스 시스템에 대한 개요를 제공합니다.
- 다양한 설계 고려사항을 이해하기 위해 각 데이터베이스가 데이터 모델링을 어떻게 처리하는지 알아봅니다.
- 쓰기 및 읽기 작업 중 데이터 경로를 비교합니다.
- 물리적 데이터 레이아웃을 검사하여 데이터베이스 아키텍처의 요소를 파악합니다.
- 요구사항에 맞게 지리적 복제를 구성하는 방법과 클러스터 크기 조정 방법을 설명합니다.
- 클러스터 관리, 모니터링, 보안에 대한 세부정보를 검토합니다.
용어 비교
Bigtable과 Cassandra에서 사용되는 많은 개념은 비슷하지만 각 데이터베이스는 약간 다른 이름 지정 규칙을 사용하며 미묘한 차이가 있습니다.
두 데이터베이스의 핵심 구성요소 중 하나는 정렬된 문자열 테이블(SSTable)입니다. SSTable은 두 아키텍처 모두에서 읽기 쿼리에 응답하는 데 사용되는 데이터를 유지하기 위해 생성됩니다.
일리아 그리고릭은 블로그 게시물(2012)에 다음과 같이 썼습니다. "SSTable은 다량의 키-값 쌍을 효율적으로 저장하면서 높은 처리량, 순차적 읽기 또는 쓰기 워크로드에 맞게 최적화하기 위한 단순한 추상화입니다."
다음 표에서는 공유 개념과 각 제품에서 사용하는 용어를 간략하게 설명합니다.
| Cassandra | Bigtable |
|---|---|
|
기본 키: 데이터 배치 및 정렬을 결정하는 고유한 단일 필드 또는 다중 필드 값입니다. 파티션 키: 일관된 해시에 따라 데이터 배치를 결정하는 단일 또는 다중 필드 값입니다. 클러스터링 열: 파티션 내에서 사전식 데이터 정렬을 결정하는 단일 또는 다중 필드 값입니다. |
row key: 사전순으로 데이터 배치를 결정하는 고유한 단일 바이트 문자열입니다. 복합 키는 해시(#) 또는 퍼센트(%) 기호 같은 공통 구분 기호를 사용하여 여러 열의 데이터를 조인하는 방식으로 표시됩니다. |
| 노드: 일련의 기본 키 파티션 해시 범위와 연결된 데이터를 읽고 쓰는 작업을 담당하는 머신입니다. Cassandra에서 데이터는 노드 서버에 연결된 블록 수준 스토리지에 저장됩니다. | 노드: 일련의 row key 범위와 연결된 데이터를 읽고 쓰는 가상 컴퓨팅 리소스입니다. Bigtable에서 데이터는 컴퓨팅 노드와 같은 위치에 있지 않습니다. 대신 Google의 분산형 파일 시스템인 Colossus에 저장됩니다. 노드에는 임시로 작업 부하 및 클러스터의 다른 노드 상태에 따라 다양한 데이터 범위를 제공하는 데는 책임이 주어집니다. |
|
데이터 센터: Bigtable 클러스터와 유사하지만 토폴로지 및 복제 전략의 일부 측면은 Cassandra에서 구성할 수 있습니다. 랙: 복제본 배치에 영향을 미치는 데이터 센터의 노드 그룹입니다. |
클러스터: 지연 시간 및 복제 문제를 방지하기 위해 같은 지리적 Google Cloud 영역에 있는 노드 그룹입니다. |
| 클러스터: 데이터 센터 모음으로 구성된 Cassandra 배포입니다. | 인스턴스: 복제 및 연결 라우팅이 발생하는 여러 Google Cloud 영역 또는 리전의 Bigtable 클러스터 그룹입니다. |
| vnode: 특정 물리적 노드에 할당된 해시 값의 고정 범위입니다. vnode의 데이터는 일련의 SSTable에 있는 Cassandra 노드에 물리적으로 저장됩니다. | 태블릿: 사전순으로 정렬된, 연속된 row key 범위에 대한 모든 데이터가 포함된 SSTable입니다. Bigtable에서는 노드에 태블릿이 저장되지 않지만 Colossus에서는 일련의 SSTable에 태블릿이 저장됩니다. |
| 복제 인수: 데이터 센터의 모든 노드에서 유지되는 vnode의 복제본 수입니다. 복제 인수는 각 데이터 센터에 대해 개별적으로 구성됩니다. | 복제: Bigtable에 저장된 데이터를 인스턴스의 모든 클러스터에 복제하는 프로세스입니다. 영역 클러스터 내의 복제는 Colossus 스토리지 레이어에서 처리됩니다. |
| 테이블(이전 명칭 column family): 값의 논리적 조직으로, 고유한 기본 키로 색인이 생성됩니다. | 테이블: 값의 논리적 조직으로, 고유한 row key로 색인이 생성됩니다. |
| 키스페이스: 포함된 테이블의 복제 계수를 정의하는 논리적 테이블 네임스페이스입니다. | 해당 없음 Bigtable은 키스페이스 문제를 투명하게 처리합니다. |
| map: 키-값 쌍을 보유하는 Cassandra 컬렉션 유형입니다. | column family: 보다 효율적인 읽기 및 쓰기를 위해 column qualifier를 그룹화하는 사용자 지정 네임스페이스입니다. SQL을 사용하여 Bigtable을 쿼리할 때 column family는 Cassandra의 맵처럼 취급됩니다. |
| 맵 키: Cassandra 맵에서 키-값 항목을 고유하게 식별하는 키입니다. | column qualifier: 테이블에 저장된 값의 라벨로, 고유한 row key로 색인이 생성됩니다. SQL을 사용하여 Bigtable을 쿼리할 때 열은 맵의 키처럼 취급됩니다. |
| 열: 테이블에 저장된 값의 라벨로, 고유한 기본 키로 색인이 생성됩니다. | 열: 테이블에 저장된 값의 라벨로, 고유한 row key로 색인이 생성됩니다. 열 이름은 column qualifier와 column family를 조합하여 구성됩니다. |
| 셀: 열과 기본 키의 교집합과 연결된 테이블의 타임스탬프 값입니다. | 셀: 열 이름과 row key의 교집합과 연결된 테이블의 타임스탬프 값입니다. 각 셀마다 타임스탬프가 지정된 여러 버전을 저장하고 검색할 수 있습니다. |
| counter: 정수 합산 연산에 최적화된 증분 가능한 필드 유형입니다. | 카운터: 정수 합산 연산에 특수 데이터 유형을 사용하는 셀입니다. 자세한 내용은 카운터 만들기 및 업데이트를 참고하세요. |
| 부하 분산 정책: 작업을 클러스터의 적절한 노드로 라우팅하도록 애플리케이션 로직에서 구성하는 정책입니다. 정책은 데이터 센터 토폴로지 및 vnode 토큰 범위를 나타냅니다. | 애플리케이션 프로필: 클라이언트 API 호출을 인스턴스의 적절한 클러스터로 라우팅하는 방법을 Bigtable에 알려주는 설정입니다. 애플리케이션 프로필을 태그로 사용하여 측정항목을 세분화할 수도 있습니다. 서비스에 애플리케이션 프로필을 구성합니다. |
| CQL: Cassandra 쿼리 언어로, 테이블 생성, 스키마 변경, 행 변형, 쿼리에 사용되는 SQL과 같은 언어입니다. | Bigtable API: 인스턴스 및 클러스터 생성, 테이블 및 column family 생성, 행 변형, 쿼리에 사용되는 클라이언트 라이브러리와 gRPC API입니다. Bigtable SQL API는 CQL 사용자에게 익숙합니다. |
제품 개요
다음 섹션에서는 Bigtable 및 Cassandra의 설계 철학 및 주요 속성을 간략하게 설명합니다.
Bigtable
Bigtable은 Bigtable: 구조화된 데이터를 위한 분산 스토리지 시스템 자료에서 설명하는 여러 핵심 기능을 제공합니다. Bigtable은 클라이언트 요청을 처리하는 컴퓨팅 노드를 기본 스토리지 관리와 분리합니다. 데이터는 Colossus에 저장됩니다. 스토리지 레이어는 표준 Hadoop 분산 파일 시스템 (HDFS) 3방향 복제에서 제공하는 수준을 초과하는 내구성을 제공하도록 데이터를 자동으로 복제합니다.
이 아키텍처는 클러스터 내에서 일관된 읽기 및 쓰기를 제공하고, 스토리지 재배포 비용 없이 확장 및 축소하며, 클러스터 또는 스키마를 수정하지 않고도 워크로드를 재조정할 수 있습니다. 데이터 처리 노드가 손상되면 Bigtable 서비스는 이를 투명하게 대체합니다. Bigtable은 비동기 복제도 지원합니다.
Bigtable은 다양한 프로그래밍 언어용 gRPC 및 클라이언트 라이브러리 외에도 Bigtable 자료의 대체 오픈소스 데이터베이스 엔진 구현인 오픈소스 Apache HBase Java 클라이언트 라이브러리와의 호환성을 유지합니다.
다음 다이어그램은 Bigtable이 처리 노드를 스토리지 레이어에서 물리적으로 분리하는 방법을 보여줍니다.
앞의 다이어그램에서 중간 처리 노드는 스토리지 레이어의 C 데이터 세트에 대한 데이터 요청 처리만 담당합니다. Bigtable이 데이터 세트에 범위 할당 재균등화가 필요하다고 판단하면 스토리지 레이어가 처리 레이어와 분리되므로 처리 노드의 데이터 범위를 쉽게 변경할 수 있습니다.
다음 다이어그램은 키 범위 재균등화 및 클러스터 크기 조절을 간략하게 보여줍니다.
재균등화 이미지는 가장 왼쪽 처리 노드가 A 데이터 세트의 증가하는 요청 수를 수신한 후 Bigtable 클러스터의 상태를 보여줍니다. 재균등화가 수행되면 가장 왼쪽 노드 대신 중간 노드가 B 데이터 세트에 대한 데이터 요청 처리를 담당합니다. 가장 왼쪽 노드는 A 데이터 세트에 대한 요청을 계속 처리합니다.
Bigtable은 증가한 가용 처리 노드 수 전반에 걸쳐 데이터 세트 범위의 균형을 맞추기 위해 row key 범위를 재정렬할 수 있습니다. 크기 조절 이미지는 노드 추가 후 Bigtable 클러스터의 상태를 보여줍니다.
Cassandra
Apache Cassandra는 Bigtable 자료의 개념에 부분적으로 영향을 받는 오픈소스 데이터베이스입니다. 분산형 데이터 아키텍처를 사용하며, 여기서 스토리지는 데이터 작업에 응답하는 서버와 함께 배치됩니다. 일련의 가상 노드(vnode)가 클러스터 키스페이스의 일부분을 처리하기 위해 각 서버에 무작위로 할당됩니다.
데이터는 파티션 키를 기준으로 vnode에 저장됩니다. 일반적으로 일관된 해시 함수를 사용하여 데이터 게재위치를 결정하는 토큰을 생성합니다. Bigtable과 마찬가지로 토큰 생성과 데이터 배치용 순서 유지 파티셔너를 사용할 수 있습니다. 하지만 Cassandra 문서에서는 이 접근법을 권장하지 않습니다. 클러스터가 불균형해져 수습하기 어려운 상태가 될 수 있기 때문입니다. 따라서 이 문서에서는 사용자가 일관된 해싱 전략을 사용하여 노드에 데이터를 분산하는 토큰을 생성한다고 가정합니다.
Cassandra는 조정 가능한 일관성 수준과 상관관계가 있는 가용성 수준을 통해 내결함성을 제공하므로 하나 이상의 노드가 손상될 경우 클러스터가 클라이언트에 서비스를 제공할 수 있습니다. 사용자는 구성 가능한 데이터 복제 토폴로지 전략을 통해 지리적 복제를 정의합니다.
각 작업에 일관성 수준을 지정합니다. 일반적인 설정은 QUORUM(또는 다중 데이터 센터 토폴로지의 경우 LOCAL_QUORUM)입니다. 이 일관성 수준 설정을 사용하려면 복제본 노드 대다수가 작업의 조정자 노드에 응답해야 성공한 것으로 간주됩니다. 모든 키 공간에 대해 구성하는 복제 인수는 클러스터의 각 데이터 센터에 저장되는 데이터 복제본 수를 결정합니다. 예를 들어 3의 복제 인수 값을 사용하여 내구성과 스토리지 볼륨 간의 실질적 균형을 제공하는 것이 일반적입니다.
다음 다이어그램은 각 노드의 키 범위가 5개의 vnode로 나누어진 노드 6개로 구성된 클러스터를 간단하게 보여줍니다. 실제로는 노드와 vnode가 더 많을 수 있습니다.
위의 다이어그램에서 클라이언트 애플리케이션 또는 서비스(클라이언트)에서 발생하는 QUORUM의 일관성 수준으로 쓰기 작업의 경로를 확인할 수 있습니다 이 다이어그램에서는 키 범위가 알파벳 범위로 표시됩니다. 실제로 기본 키의 해시로 생성된 토큰은 매우 큰 부호 있는 정수입니다.
이 예시에서 키 해시는 M이고 M의 vnode는 노드 2, 4, 6에 있습니다. 조정자는 쓰기가 처리될 수 있도록 키 해시 범위가 로컬로 저장된 각 노드를 확인해야 합니다. 일관성 수준은 QUORUM이므로 2개의 복제본(대부분)이 조정자 노드에 응답해야 클라이언트에 쓰기가 완료되었다는 알림이 전송됩니다.
Bigtable과 달리 Cassandra에서 키 범위를 이동하거나 변경하려면 데이터를 한 노드에서 다른 노드로 물리적으로 복사해야 합니다. 특정 토큰 해시 범위에 대한 요청으로 노드 하나가 오버로드되는 경우 해당 토큰 범위에 대한 처리를 추가하는 작업이 Cassandra에서는 Bigtable에 비해 더 복잡합니다.
지리적 복제 및 일관성
Bigtable과 Cassandra는 지리적(멀티 리전이라고도 함) 복제 및 일관성을 다르게 처리합니다. Cassandra 클러스터는 랙으로 그룹화된 처리 노드로 구성되며 랙은 데이터 센터로 그룹화됩니다. Cassandra는 구성된 네트워크 토폴로지 전략을 사용하여 vnode 복제본이 데이터 센터의 호스트에 분산되는 방식을 결정합니다. 이 전략은 Cassandra의 루트를 원래 실제 온프레미스 데이터 센터에 배포된 데이터베이스로 사용할 수 있습니다. 이 구성은 클러스터의 각 데이터 센터에 대한 복제 인수도 지정합니다.
Cassandra는 데이터 센터와 랙 구성을 사용하여 데이터 복제본의 내결함성을 개선합니다. 읽기 및 쓰기 작업 도중 토폴로지는 일관성 보장을 제공하는 데 필요한 참여자 노드를 결정합니다. 클러스터를 만들거나 확장할 때 노드, 랙, 데이터 센터를 수동으로 구성해야 합니다. 클라우드 환경 내에서 일반적인 Cassandra 배포는 클라우드 영역을 랙으로, 클라우드 리전을 데이터 센터로 취급합니다.
Cassandra의 쿼럼 제어를 사용하여 각 읽기 또는 쓰기 작업의 일관성 보장을 조정할 수 있습니다. 단일 복제본 노드(ONE), 단일 데이터 센터 복제본 노드 대다수(LOCAL_QUORUM) 또는 모든 데이터 센터(QUORUM)의 복제본 노드 중 대다수가 필요한 옵션을 포함하여 eventual consistency의 강도가 변동될 수 있습니다.
Bigtable에서 클러스터는 영역별 리소스입니다. Bigtable 인스턴스에는 단일 클러스터가 포함되거나 완전히 복제된 클러스터의 그룹이 될 수 있습니다. Google Cloud에서 제공하는 모든 리전의 영역 조합에 인스턴스 클러스터를 배치할 수 있습니다. 인스턴스의 다른 클러스터에 미치는 영향을 최소화하면서 인스턴스에서 클러스터를 추가하거나 삭제할 수 있습니다.
Bigtable에서는 단일 클러스터에서 작성한 항목을 읽을 수 있는 일관성을 사용하여 쓰기가 수행되고, 다른 인스턴스 클러스터에서 eventual consistency를 갖게 됩니다. 개별 셀은 타임스탬프에 따라 버전이 관리되므로 쓰기가 손실되지 않으며 각 클러스터는 현재 타임스탬프가 최신인 셀을 처리합니다.
서비스가 클러스터 일관성 상태를 노출합니다. Cloud Bigtable API는 테이블 수준 일관성 토큰을 가져오는 메커니즘을 제공합니다. 이 토큰을 사용하면 토큰이 생성되기 전에 테이블에 적용된 모든 변경사항이 완전히 복제되었는지 확인할 수 있습니다.
트랜잭션 지원
두 데이터베이스 모두 복잡한 다중 행 트랜잭션을 지원하지 않지만 각 데이터베이스는 일부 트랜잭션을 지원합니다.
Cassandra에는 단일 파티션의 열 값 업데이트를 위해 원자성을 제공하는 경량 트랜잭션 (LWT) 메서드가 있습니다. 또한 Cassandra에는 쓰기 시작 전에 행 읽기 작업 및 값 비교를 완료하는 비교 및 설정 시맨틱스가 있습니다.
Bigtable은 클러스터 내에서 완전히 일관된 단일 행 쓰기를 지원합니다. 읽기-수정-쓰기 및 검사 및 변형 작업을 통해 단일 행 트랜잭션을 추가로 사용 설정할 수 있습니다. 멀티 클러스터 라우팅 애플리케이션 프로필은 단일 행 트랜잭션을 지원하지 않습니다.
데이터 모델
Bigtable과 Cassandra는 모두 행의 고유 식별자를 사용하여 조회 및 범위 스캔을 지원하는 테이블로 데이터를 구성합니다. 두 시스템 모두 NoSQL 와이드 칼럼 저장소로 분류됩니다.
Cassandra에서는 기본 키 정의와 함께 열 이름 및 유형을 포함하여 전체 테이블 스키마를 미리 만들려면 CQL을 사용해야 합니다. Cassandra의 기본 키는 필수 파티션 키와 선택적 클러스터 키로 구성된 고유한 복합 값입니다. 파티션 키는 행의 노드 배치를 결정하며 클러스터 키는 파티션 내의 정렬 순서를 결정합니다. 스키마를 만들 때는 단일 파티션 내에서 효율적인 스캔을 실행하는 것과 대규모 파티션 유지관리와 관련된 시스템 비용 간에 잠재적인 절충점이 있을 수 있음을 인식해야 합니다.
Bigtable에서는 테이블을 만들고 column family를 미리 정의하기만 하면 됩니다. 테이블을 만들 때 열이 선언되지 않지만 애플리케이션 API 호출이 테이블 행에 셀을 추가하면 열이 생성됩니다.
row key는 Bigtable 클러스터에서 사전순으로 정렬됩니다. Bigtable 내 노드는 보통 태블릿으로 불리며 분할이라고도 불리는 키 범위에 대한 노드별 책임의 균형을 자동으로 유지합니다. Bigtable row key는 원하는 자주 사용되는 구분 기호 문자(예: 퍼센트 기호)를 사용하여 조인되는 여러 필드 값으로 구성되는 경우가 많습니다. 구분된 경우 각 문자열 구성요소는 Cassandra 기본 키의 필드와 유사합니다.
row key 설계
Bigtable에서 테이블 행의 고유 식별자는 row key입니다. row key는 전체 테이블에 걸쳐 하나의 고유한 값이어야 합니다. 공통 구분 기호로 구분된 분산된 요소를 연결하여 멀티 파트 키를 만들 수 있습니다. row key는 테이블의 전체적인 데이터 정렬 순서를 결정합니다. Bigtable 서비스는 각 노드에 할당되는 키 범위를 동적으로 결정합니다.
파티션 키 해시가 행 배치를 결정하고 클러스터링 열이 정렬 순서를 결정하는 Cassandra와 달리 Bigtable row key는 노드 할당과 정렬 순서를 모두 제공합니다. Cassandra와 마찬가지로, 검색할 행을 함께 저장하도록 Bigtable에서 row key를 설계해야 합니다. 그러나 Bigtable에서는 테이블을 사용하기 전에 배치 및 정렬을 위해 row key를 설계할 필요가 없습니다.
데이터 유형
Bigtable 서비스는 클라이언트가 보내는 열 데이터 유형을 적용하지 않습니다. 클라이언트 라이브러리는 셀 값을 바이트, UTF-8로 인코딩된 문자열, Big Endian으로 인코딩된 64비트 정수(원자적 증분 연산에는 Big Endian으로 인코딩 정수 필요)로 작성하는 도우미 메서드를 제공합니다.
Column family
Bigtable에서 column family는 테이블에서 함께 저장 및 검색되는 열을 결정합니다. 각 테이블에는 하나 이상의 column family가 필요하지만 테이블에는 더 많은 column family가 있습니다(테이블당 100개의 column family로 제한). 애플리케이션이 작업에서 column family를 사용할 수 있게 하려면 column family를 명시적으로 만들어야 합니다.
Column Qualifier
row key의 테이블에 저장되는 각 값은 column qualifier라는 라벨과 연결됩니다. column qualifier는 라벨일 뿐이므로 column family에 사용할 수 있는 열 수에는 실질적 제한이 없습니다. Bigtable에서는 주로 애플리케이션 데이터를 나타내는 column qualifier를 사용합니다.
셀
Bigtable에서 셀은 row key와 열 이름(column qualifier와 결합된 column family)의 교집합입니다. 각 셀에는 클라이언트가 제공하거나 서비스에서 자동으로 적용하는 타임스탬프 값이 한 개 이상 포함됩니다. 이전 셀 값은 column family 수준에서 구성된 가비지 컬렉션 정책에 따라 회수됩니다.
보조 색인
Bigtable은 보조 색인을 지원하지 않습니다. 색인이 필요한 경우 다른 row key가 있는 두 번째 테이블을 사용하는 테이블 설계를 사용하는 것이 좋습니다.
클라이언트 부하 분산 및 장애 조치
Cassandra에서 클라이언트는 요청의 부하 분산을 제어합니다. 클라이언트 드라이버는 구성의 일부로 지정되거나 세션 생성 중에 프로그래매틱 방식으로 지정된 정책을 설정합니다. 클러스터는 애플리케이션에 가장 가까운 데이터 센터에 대한 정책을 알리고, 클라이언트는 이러한 데이터 센터의 노드를 파악하여 작업을 처리합니다.
Bigtable 서비스는 각 작업과 함께 제공된 매개변수(애플리케이션 프로필 식별자)를 기반으로 대상 클러스터로 API 호출을 라우팅합니다. 애플리케이션 프로필은 Bigtable 서비스 내에서 유지됩니다. 프로필을 선택하지 않는 클라이언트 작업은 기본 프로필을 사용합니다.
Bigtable에는 단일 클러스터 및 멀티 클러스터이라는 두 가지 유형의 애플리케이션 프로필 라우팅 정책이 있습니다. 멀티 클러스터 프로필은 사용 가능한 가장 가까운 클러스터로 작업을 라우팅합니다. 동일한 리전의 클러스터는 작업 라우터의 관점에서는 등거리로 간주됩니다. 요청된 키 범위를 담당하는 노드가 오버로드되거나 클러스터에서 일시적으로 사용할 수 없는 경우 이 프로필 유형이 자동 장애 조치를 제공합니다.
Cassandra의 경우 멀티 클러스터 정책이 데이터 센터를 인식하는 부하 분산 정책의 장애 조치 이점을 제공합니다.
단일 클러스터 라우팅을 사용하는 애플리케이션 프로필은 모든 트래픽을 단일 클러스터로 전달합니다. 강력한 행 일관성과 단일 행 트랜잭션은 단일 클러스터 라우팅을 사용하는 프로필에서만 사용할 수 있습니다.
단일 클러스터 접근 방식의 단점은 장애 조치 시 애플리케이션이 대체 애플리케이션 프로필 식별자를 사용하여 재시도하거나 영향을 받은 단일 클러스터 라우팅 프로필의 장애 조치를 수동으로 수행해야 한다는 점입니다.
작업 라우팅
Cassandra와 Bigtable은 다양한 방법을 사용하여 읽기 및 쓰기 작업의 처리 노드를 선택합니다. Cassandra에서 파티션 키는 식별되지만 Bigtable에서는 row key가 사용됩니다.
Cassandra에서 클라이언트는 먼저 부하 분산 정책을 검사합니다. 이 클라이언트 측 객체는 작업이 라우팅되는 데이터 센터를 결정합니다.
데이터 센터가 식별되면 Cassandra가 조정자 노드를 참조하여 작업을 관리합니다. 정책이 토큰을 인식하면 조정자가 대상 vnode 파티션의 데이터를 처리하는 노드입니다. 그렇지 않으면 조정자는 무작위 노드입니다. 조정자 노드는 작업 파티션 키의 데이터 복제본이 위치한 노드를 식별한 후 해당 노드에 작업을 수행하도록 지시합니다.
Bigtable에서는 앞에서 설명한 것처럼 각 작업에 애플리케이션 프로필 식별자가 포함되어 있습니다. 애플리케이션 프로필은 서비스 수준에서 정의됩니다. Bigtable 라우팅 레이어에서 프로필을 검사하여 작업에 적합한 대상 클러스터를 선택합니다. 그러면 라우팅 레이어가 작업의 row key를 사용하여 올바른 처리 노드에 도달할 수 있도록 경로를 제공합니다.
데이터 쓰기 프로세스
두 데이터베이스 모두 빠른 쓰기에 최적화되어 있으며 유사한 프로세스를 사용하여 쓰기를 완료합니다. 그러나 특히 작업 일관성 수준에 따라 추가 참여자 노드와의 통신이 필요할 수 있는 Cassandra의 경우 데이터베이스에서 수행하는 단계가 다릅니다
쓰기 요청이 적절한 노드(Cassandra) 또는 노드(Bigtable)로 라우팅되면 쓰기가 우선 디스크의 커밋 로그(Cassandra) 또는 공유 로그(Bigtable)에 순차적으로 유지됩니다. 그런 다음 SSTable과 같이 순서가 지정된 메모리 내 테이블(memtable이라고도 함)에 쓰기가 삽입됩니다.
이 두 단계가 완료되면 노드는 쓰기가 완료되었다고 응답합니다. Cassandra에서 여러 복제본은 각 작업에 지정된 일관성 수준에 따라 조정자가 쓰기 완료를 클라이언트에 알리기 전에 응답해야 합니다. Bigtable에서 각 row key는 특정 시점에 단일 노드에만 할당되기 때문에 쓰기가 성공했는지 확인하는 데 필요한 것은 노드 응답밖에 없습니다.
필요한 경우 나중에 memtable을 새 SSTable의 형식의 디스크로 플러시할 수 있습니다. Cassandra에서 플러시는 커밋 로그가 최대 크기에 도달하거나 mumtable이 구성한 기준점을 초과하면 발생합니다. Bigtable에서 플러시가 시작되어 memtable이 서비스에 지정된 최대 크기에 도달하면 변경할 수 없는 새 SSTable을 만듭니다. 압축 프로세스는 지정된 키 범위의 SSTable을 단일 SSTable로 주기적으로 병합합니다.
데이터 업데이트
두 데이터베이스는 데이터 업데이트를 유사하게 처리합니다. 하지만 Cassandra는 각 셀당 하나의 값만 허용하지만 Bigtable은 각 셀에 많은 수의 버전 관리 값을 유지할 수 있습니다.
고유한 행 식별자와 열의 교집합에 있는 값이 수정된 경우 데이터 쓰기 프로세스 섹션에서 앞서 설명한 것처럼 업데이트가 유지됩니다. 쓰기 타임스탬프는 SSTable 구조의 값과 함께 저장됩니다.
업데이트된 셀을 SSTable로 플러시하지 않은 경우 memtable에만 셀 값을 저장할 수 있지만 데이터베이스에서 저장하는 항목은 다릅니다. Cassandra는 memtable에 최신 값만 저장하지만 Bigtable은 모든 버전을 memtable에 저장합니다.
또는 하나 이상의 셀 값 버전을 개별 SSTable의 디스크로 플러시한 경우에는 데이터베이스가 해당 데이터에 대한 요청을 다르게 처리합니다. Cassandra에서 셀을 요청하면 타임스탬프에 따라 가장 최근 값만 반환됩니다. 다시 말하면 마지막 쓰기가 적용됩니다. Bigtable에서는 필터를 사용하여 읽기 요청이 반환하는 셀의 버전을 제어합니다.
행 삭제
두 데이터베이스 모두 변경할 수 없는 SSTable 파일을 사용하여 데이터를 디스크에 유지하므로 행을 즉시 삭제할 수 없습니다. 행이 삭제된 후 쿼리가 올바른 결과를 반환하도록 두 데이터베이스 모두 동일한 메커니즘을 사용하여 삭제를 처리합니다. 먼저 memtable에 마커(Cassandra에서는 Tombstone이라고 함)가 추가됩니다. 결국 새로 작성된 SSTable은 고유한 행 식별자가 삭제되었고 쿼리 결과에 반환되어서는 안 된다는 것을 나타내는 타임스탬프가 적용된 마커를 포함합니다.
라이브까지의 시간
두 데이터베이스의 TTL(수명) 기능은 한 가지 차이점을 제외하면 유사합니다. Cassandra에서는 열 또는 테이블의 TTL을 설정할 수 있지만 Bigtable에서는 column family에만 TTL을 설정할 수 있습니다. 셀 수준 TTL을 시뮬레이션할 수 있는 Bigtable용 메서드가 있습니다.
가비지 컬렉션
앞서 설명한 것처럼 변경 불가능한 SSTable에서는 데이터를 즉시 업데이트하거나 삭제할 수 없기 때문에 압축 프로세스 중에 가비지 컬렉션이 발생합니다. 이 프로세스는 쿼리 결과에 제공해서는 안 되는 셀 또는 행을 삭제합니다.
가비지 컬렉션 프로세스는 SSTable 병합이 발생할 때 행 또는 셀을 제외합니다. 행에 마커 또는 Tombstone이 있는 경우, 해당 행은 결과 SSTable에 포함되지 않습니다. 두 데이터베이스 모두 병합된 SSTable에서 셀을 제외할 수 있습니다. 셀 타임스탬프가 TTL 자격을 초과하면 데이터베이스는 셀을 제외합니다. 지정된 셀에 타임스탬프가 지정된 버전이 2개 있는 경우 Cassandra는 병합된 SSTable에 최신 값만 포함합니다.
데이터 읽기 경로
두 데이터베이스에서 읽기 작업이 적절한 처리 노드에 도달하면 쿼리 결과를 충족하기 위해 데이터를 가져오는 읽기 프로세스는 동일합니다.
쿼리 결과를 포함할 수 있는 디스크의 각 SSTable에는 각 파일에 반환할 행이 있는지 확인하는 Bloom 필터가 선택됩니다. Bloom 필터는 거짓음성을 제공하지 않는다고 보장할 수 있기 때문에 모든 적격 SSTable이 추가 읽기 결과 처리에 포함할 후보 목록에 추가됩니다.
읽기 작업은 디스크의 memtable과 후보 SSTable을 사용하여 생성된 병합 뷰로 수행됩니다. 모든 키는 사전순으로 정렬되므로 쿼리 결과를 얻으려면 검사가 완료된, 병합된 뷰를 가져오는 것이 효율적입니다.
Cassandra에서는 작업 일관성 수준에 따라 결정된 처리 노드 집합이 작업에 참여해야 합니다. Bigtable에서는 키 범위를 담당하는 노드만 참조해야 합니다. Cassandra의 경우 여러 노드가 각 읽기를 처리할 가능성이 높으므로 컴퓨팅 크기 조절의 영향을 고려해야 합니다.
읽기 결과는 처리 노드에서 약간 다른 방식으로 제한될 수 있습니다.
Cassandra에서 CQL 쿼리의 WHERE 절은 반환되는 행을 제한합니다. 제약조건은 기본 키의 열 또는 보조 색인에 포함된 열을 사용하여 결과를 제한할 수 있다는 것입니다.
Bigtable은 읽기 쿼리가 검색하는 행 또는 셀에 영향을 주는 리치 필터 분류를 제공합니다.
필터에는 다음과 같은 세 가지 카테고리가 있습니다.
- 응답에 포함되는 행 또는 셀을 제어하는 제한 필터.
- 개별 셀의 데이터 또는 메타데이터에 영향을 주는 수정 필터.
- 여러 필터를 하나의 필터로 결합할 수 있는 복합 필터.
가장 일반적으로 사용되는 필터는 제한 필터입니다. 예를 들어 column family 정규 표현식과 column qualifier 정규 표현식이 있습니다.
물리적 데이터 스토리지
Bigtable과 Cassandra는 모두 데이터를 SSTable에 저장합니다. SSTable은 압축 단계에서 정기적으로 병합됩니다. SSTable 데이터 압축은 스토리지 크기를 줄이는 것과 유사한 이점을 제공합니다. 하지만 압축은 Bigtable에서 자동으로 적용되지만 Cassandra에서는 구성 옵션입니다.
두 데이터베이스를 비교할 때는 다음과 같은 측면에서 각 데이터베이스가 물리적으로 데이터를 저장하는 방법이 어떻게 다른지 이해해야 합니다.
- 데이터 배포 전략
- 사용 가능한 셀 버전 수
- 스토리지 디스크 유형
- 데이터 내구성 및 복제 메커니즘
데이터 배포
Cassandra에서는 클러스터 노드에서 제공하는 다양한 SSTable에 대한 데이터 배포를 결정할 때 기본 키 파티션 열의 일관된 해시가 권장됩니다.
Bigtable은 전체 row key에 대한 변수 프리픽스를 사용하여 데이터를 SSTable에 사전순으로 배치합니다.
셀 버전
Cassandra는 활성 셀 값 버전을 하나만 유지합니다. 셀에 2개의 쓰기가 기록되면 last-write-wins 정책에 따라 값이 하나만 반환됩니다.
Bigtable은 각 셀의 타임스탬프가 적용된 버전의 수를 제한하지 않습니다. 다른 행 크기 제한이 적용될 수 있습니다. 클라이언트 요청으로 설정하지 않으면 처리 노드가 변형을 수신하는 시점에 타임스탬프가 Bigtable 서비스에 의해 결정됩니다. 셀 버전은 각 테이블의 column family마다 다를 수 있거나 API를 통해 설정된 쿼리 결과에서 필터링될 수 있는 가비지 컬렉션 정책을 사용하여 프루닝할 수 있습니다.
디스크 스토리지
Cassandra는 각 클러스터 노드에 연결된 디스크에 SSTable을 저장합니다. Cassandra에서 데이터의 균형을 다시 유지하려면 파일을 서버 간에 물리적으로 복사해야 합니다.
Bigtable은 Colossus를 사용하여 SSTable을 저장합니다. Bigtable은 이 분산형 파일 시스템을 사용하므로 Cloud Bigtable 서비스가 SSTable을 즉시 다른 노드에 재할당할 수 있습니다.
데이터 내구성 및 복제
Cassandra는 복제 인수 설정을 통해 데이터 내구성을 제공합니다. 복제 인수는 클러스터의 다른 노드에 저장되는 SSTable 사본 수를 결정합니다. 복제 인수에 대한 일반적인 설정은 3입니다. 이렇게 하면 노드 오류가 발생해도 QUORUM 또는 LOCAL_QUORUM과의 strong consistency 보장이 허용됩니다.
Bigtable을 사용하면 Colossus에서 제공하는 복제를 통해 높은 데이터 내구성 보장이 제공됩니다.
다음 다이어그램은 Bigtable의 물리적 데이터 레이아웃, 컴퓨팅 처리 노드, 라우팅 레이어를 보여줍니다.
Colossus 스토리지 레이어에서는 각 노드가 할당되어 일련의 SSTables에 저장된 데이터를 제공합니다. 이러한 SSTable에는 각 노드에 동적으로 할당되는 row key 범위의 데이터가 포함됩니다. 다이어그램에 노드당 세 개의 SSTable이 표시되어 있지만 노드가 새로운 데이터 변경사항을 수신하면 SSTable이 지속적으로 변경되기 때문에 더 많은 SSTable이 있을 가능성이 큽니다.
각 노드에는 공유 로그가 있습니다. 클라이언트가 쓰기 확인을 받기 전에 각 노드에서 처리된 쓰기는 공유 로그에 즉시 유지됩니다. Colossus에 대한 쓰기가 여러 번 복제되므로 데이터가 행 범위에 대해 SSTable에 유지되기 전에 노드 하드웨어 오류가 발생하더라도 내구성이 보장됩니다.
애플리케이션 인터페이스
원래 Cassandra 데이터베이스 액세스는 Thrift API를 통해 노출되었지만 이러한 액세스 방식은 지원 중단되었습니다. 클라이언트 상호작용의 권장사항은 CQL을 사용하는 것입니다.
Cassandra의 원래 Thrift API와 마찬가지로 Bigtable 데이터베이스 액세스도 제공된 row key를 기준으로 데이터를 읽고 쓰는 API를 통해 제공됩니다.
Cassandra와 마찬가지로 Bigtable에는 cbt CLI라는 명령줄 인터페이스와 여러 일반적인 프로그래밍 언어를 지원하는 클라이언트 라이브러리가 모두 있습니다. 이러한 라이브러리는 gRPC와 REST API를 기반으로 빌드됩니다. Hadoop용으로 작성되었으며 Java용 오픈소스 Apache HBase 라이브러리를 사용하는 애플리케이션은 중요한 변경사항 없이 Bigtable에 연결할 수 있습니다. HBase 호환성이 필요하지 않은 애플리케이션에서는 기본 제공 Bigtable 자바 클라이언트를 사용하는 것이 좋습니다.
Bigtable의 Identity and Access Management (IAM) 컨트롤은 Google Cloud와 완전히 통합되며, 테이블을 BigQuery의 외부 데이터 소스로 사용할 수도 있습니다.
데이터베이스 설정
Cassandra 클러스터를 설정할 때 결정할 구성과 완료해야 할 단계가 있습니다. 먼저 컴퓨팅 용량을 제공하고 로컬 스토리지를 프로비저닝하도록 서버 노드를 구성해야 합니다. 가장 일반적이며 권장되는 설정인 복제 인수 3을 사용하는 경우, 클러스터에 보관할 데이터 양의 3배를 저장하는 스토리지를 프로비저닝해야 합니다. 또한 vnode, 랙, 복제에 대한 구성을 결정하고 설정해야 합니다.
Bigtable에서 스토리지와 컴퓨팅을 분리하면 Cassandra보다 간편하게 클러스터를 확장하거나 축소할 수 있습니다. 정상적으로 실행되는 클러스터에서는 일반적으로 최소 노드 수를 결정하는 관리형 테이블에 사용되는 총 저장용량과 현재 QPS를 유지하기에 충분한 노드가 있는지 여부만 고려하면 됩니다.
프로덕션 부하를 기반으로 클러스터가 과소 프로비저닝되거나 과다 프로비저닝된 경우 Bigtable 클러스터 크기를 빠르게 조정할 수 있습니다.
Bigtable 스토리지
Bigtable 인스턴스를 만들 때는 초기 클러스터의 지리적 위치 외에 스토리지 유형만 선택하면 됩니다. Bigtable은 솔리드 스테이트 드라이브(SSD) 또는 하드 디스크 드라이브 (HDD)라는 두 가지 스토리지 옵션을 제공합니다. 인스턴스의 모든 클러스터는 동일한 스토리지 유형을 공유해야 합니다.
Bigtable과 관련한 스토리지 요구사항을 고려할 때는 Cassandra 클러스터의 크기를 조절할 때와 같이 스토리지 복제본을 고려하지 않아도 됩니다. Cassandra처럼 내결함성을 구현하기 위해 스토리지 밀도가 손실되지 않습니다. 또한 스토리지를 명시적으로 프로비저닝할 필요가 없기 때문에 사용한 스토리지에 대해서만 요금이 청구됩니다.
SSD
대부분의 워크로드에서 권장되는 5TB의 SSD 노드 용량은 Cassandra 머신의 권장 구성과 비교하여 높은 스토리지 밀도를 제공합니다. Cassandra 머신에서 각 노드의 실질적인 최대 스토리지 밀도는 2TB 미만입니다. Bigtable이 필요한 스토리지 용량을 평가할 때 데이터의 복사본 하나만 고려하는 반면, Cassandra는 대부분의 구성에서 데이터 사본 3개를 고려해야 합니다.
SSD의 쓰기 QPS는 HDD와 거의 동일하지만 SSD는 HDD보다 훨씬 높은 읽기 QPS를 제공합니다. SSD 스토리지는 프로비저닝된 SSD 영구 디스크의 비용에 가깝게 가격이 책정되며 리전별로 다릅니다.
HDD
HDD 스토리지 유형은 각 노드에 상당한 스토리지 밀도(16TB)를 허용합니다. 단점은 무작위 읽기가 상당히 느려 각 노드에서 초당 500개 행 읽기만 지원된다는 점입니다. HDD는 일괄 처리와 관련된 범위 스캔이 읽기가 될 것으로 예상되는 쓰기 집약적 워크로드에 적합합니다. HDD 스토리지의 가격은 Cloud Storage와 관련된 비용 또는 근사치로 책정되며 리전별로 다릅니다.
클러스터 크기 고려사항
Cassandra 워크로드 마이그레이션을 준비하기 위해 Bigtable 인스턴스의 크기를 조정하는 경우 단일 데이터 센터 Cassandra 클러스터를 단일 클러스터 Bigtable 인스턴스에, Cassandra 멀티 데이터 센터 클러스터를 멀티 클러스터 Bigtable 인스턴스에 비교할 때 고려할 사항이 있습니다. 다음 섹션의 가이드에서는 마이그레이션 시 중요한 데이터 모델 변경이 필요 없고 Cassandra와 Bigtable의 스토리지 압축이 동일하다고 가정합니다.
단일 데이터 센터 클러스터
단일 데이터 센터 클러스터를 단일 클러스터 Bigtable 인스턴스와 비교할 때는 먼저 스토리지 요구사항을 고려해야 합니다. nodetool tablestats 명령어를 사용하고 플러시된 총 스토리지 크기를 키스페이스의 복제 인수로 나누어 각 키스페이스의 복제되지 않은 크기를 예측할 수 있습니다. 그런 다음 모든 키스페이스의 복제되지 않은 스토리지 용량을 3.5TB(5TB * .70)로 나누어 스토리지만 처리하도록 제안되는 SSD 노드 수를 결정합니다. 이미 설명한 것처럼 Bigtable은 사용자에게 투명한 별도의 계층 내에서 스토리지 복제 및 내구성을 처리합니다.
다음으로 노드 수에 대한 컴퓨팅 요구사항을 고려해야 합니다. Cassandra 서버 및 클라이언트 애플리케이션 측정항목을 참조하여 실행된 읽기 및 쓰기의 대략적인 개수를 구할 수 있습니다. 워크로드를 수행하기 위한 최소 SSD 노드 수를 추정하려면 해당 측정항목을 10,000으로 나눕니다. 지연 시간이 짧은 쿼리 결과가 필요한 애플리케이션에 더 많은 노드가 필요할 수 있습니다. 대표 데이터와 쿼리로 Bigtable의 성능을 테스트하여 워크로드가 달성할 수 있는 노드별 QPS에 대한 측정항목을 설정하는 것이 좋습니다.
클러스터에 필요한 노드 수는 스토리지 및 컴퓨팅 요구사항 중 더 큰 수와 동일해야 합니다. 스토리지 또는 처리량 요구사항이 확실하지 않은 경우 Bigtable 노드 수를 일반 Cassandra 머신 수와 일치시킬 수 있습니다. 최소한의 노력으로 다운타임 없이 워크로드 요구사항에 맞게 Bigtable 클러스터를 확장 또는 축소할 수 있습니다.
멀티 데이터 센터 클러스터
멀티 데이터 센터 클러스터가 있으면 Bigtable 인스턴스의 구성을 결정하기가 더 어렵습니다. 이상적으로는 Cassandra 토폴로지의 모든 데이터 센터에 대한 인스턴스에 클러스터가 있는 것이 좋습니다. 인스턴스의 각 Bigtable 클러스터는 모든 데이터를 인스턴스 내에 저장해야 하고 전체 클러스터에서 총 삽입 비율을 처리할 수 있어야 합니다. 인스턴스의 클러스터는 전 세계에서 지원되는 클라우드 리전에서 생성될 수 있습니다.
스토리지 요구사항을 예측하기 위한 기법은 단일 데이터 센터 클러스터를 위한 접근 방식과 유사합니다. nodetool을 사용하여 Cassandra 클러스터에 있는 각 키스페이스의 스토리지 크기를 캡처한 후 이 크기를 복제본 수로 나눕니다. 테이블의 키스페이스에는 각 데이터 센터마다 복제 인수가 다를 수 있습니다.
인스턴스의 각 클러스터에 있는 노드 수는 클러스터 서비스 중단 시 서비스 수준 목표 (SLO)를 유지하기 위해 클러스터 전체에서 모든 쓰기를 처리하고 2개 이상의 데이터 센터에 대한 모든 읽기를 처리할 수 있어야 합니다. 일반적인 접근 방식은 Cassandra 클러스터에서 가장 많이 사용되는 데이터 센터의 노드 용량이 동일한 모든 클러스터부터 시작하는 것입니다. 인스턴스의 Bigtable 클러스터는 다운타임 없이 워크로드 요구사항과 일치하도록 개별적으로 확장하거나 축소할 수 있습니다.
관리
Bigtable은 Cassandra에서 수행되는 일반적인 관리 함수에 대한 완전 관리형 구성요소를 제공합니다.
백업 및 복원
Bigtable은 일반적인 백업 요구사항을 처리하기 위해 Bigtable 백업과 관리형 데이터 내보내기라는 두 가지 방법을 제공합니다.
Bigtable 백업은 Cassandra의 nodetool 스냅샷 기능의 관리형 버전과 비슷한 개념입니다.
Bigtable 백업은 클러스터의 구성원 객체로 저장되는 테이블의 복원 가능한 사본을 만듭니다. 백업을 시작한 클러스터의 새 테이블로 백업을 복원할 수 있습니다. 백업은 애플리케이션 수준의 손상이 발생할 경우 복원 지점을 만들도록 설계되었습니다. 이 유틸리티를 통해 만든 백업은 노드 리소스를 사용하지 않고 Cloud Storage 가격과 동일하거나 유사한 가격이 책정됩니다. Bigtable 백업은 프로그래매틱 방식 또는 Bigtable용 Google Cloud 콘솔을 통해 호출할 수 있습니다.
Bigtable을 백업하는 또 다른 방법은 Cloud Storage로 관리형 데이터 내보내기를 사용하는 것입니다. Avro, Parquet 또는 Hadoop 시퀀스 파일 형식으로 내보낼 수 있습니다. 내보내기는 Dataflow를 사용하므로 Bigtable 백업에 비해 내보내기에 더 많은 시간이 걸리고 추가적인 컴퓨팅 비용이 발생합니다. 하지만 이러한 내보내기는 오프라인으로 쿼리하거나 다른 시스템으로 가져올 수 있는 이동형 데이터 파일을 만듭니다.
크기 조정
Bigtable은 스토리지와 컴퓨팅을 분리하므로 쿼리 수요에 대한 응답으로 Bigtable 노드를 추가하거나 제거하기가 Cassandra보다 훨씬 더 원활합니다. Cassandra의 동종 아키텍처를 적용하려면 클러스터의 머신에서 노드(또는 vnode)를 재균등화해야 합니다.
Google Cloud 콘솔에서 수동으로 또는 Cloud Bigtable API를 사용하여 프로그래매틱 방식으로 클러스터 크기를 변경할 수 있습니다. 클러스터에 노드를 추가하면 몇 분 내에 성능이 크게 개선됩니다. 일부 고객은 Spotify에서 개발한 오픈소스 자동 확장 처리를 성공적으로 사용했습니다.
내부 유지보수
Bigtable 서비스는 OS 패치, 노드 복구, 노드 복원, 스토리지 압축 모니터링, SSL 인증서 순환과 같은 일반적인 Cassandra 내부 유지보수 작업을 원활하게 처리합니다.
모니터링
Bigtable을 측정항목 시각화 또는 알림에 연결하면 관리 또는 개발 작업이 필요하지 않습니다. Bigtable Google Cloud 콘솔 페이지에는 인스턴스, 클러스터, 테이블 수준에서 처리량 및 사용률 측정항목을 추적할 수 있는 사전 제작된 대시보드가 제공됩니다. Cloud Monitoring 대시보드에서 커스텀 뷰 및 알림을 만들 수 있으며 측정항목이 자동으로 제공됩니다.
Google Cloud 콘솔의 모니터링 기능인 Bigtable Key Visualizer를 사용하여 고급 성능 미세 조정을 수행할 수 있습니다.
IAM 및 보안
Bigtable에서 승인은 Google Cloud의 IAM 프레임워크에 완전히 통합되어 있으며 최소한의 설정 및 유지보수가 필요합니다. 로컬 사용자 계정과 비밀번호는 클라이언트 애플리케이션과 공유되지 않습니다. 대신 세분화된 권한 및 역할이 조직 수준의 사용자와 서비스 계정에 부여됩니다.
Bigtable은 모든 저장 데이터 및 전송 중 데이터를 자동으로 암호화합니다. 이 기능을 사용 중지하는 옵션은 없습니다. 모든 관리 액세스가 완전히 로깅됩니다. VPC 서비스 제어를 사용하면 승인된 네트워크 외부의 Bigtable 인스턴스에 대한 액세스를 제어할 수 있습니다.
다음 단계
- Bigtable 스키마 디자인 읽어보기
- Cassandra 사용자를 위한 Bigtable Codelab 사용해 보기
- Bigtable 에뮬레이터 알아보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴보세요. Cloud 아키텍처 센터를 살펴보세요.