DynamoDB 사용자를 위한 Bigtable

이 문서는 Bigtable에 데이터 스토어로 사용할 애플리케이션을 마이그레이션 또는 설계하려는 DynamoDB 개발자 및 데이터베이스 관리자를 대상으로 합니다. 이 문서를 읽기 전에 Bigtable 개요를 읽어보세요.

Bigtable 및 DynamoDB는 수백만 개의 초당 쿼리 수(QPS)를 지원하고, 페타바이트급 데이터로 확장되는 스토리지를 제공하고, 노드 오류를 견딜 수 있는 분산된 키-값 저장소입니다.

이러한 데이터베이스 서비스는 기능 집합이 서로 비슷하지만 마이그레이션을 시작하기 전에 여러 측면에서 기본 아키텍처와 상호작용 세부정보 간의 차이점을 이해하는 것이 중요합니다. 이 문서에서는 두 데이터베이스 시스템의 유사점과 차이점을 설명합니다.

제어 영역

DynamoDB 및 Bigtable에서는 제어 영역을 통해 용량을 구성하고 리소스를 설정 및 관리할 수 있습니다. DynamoDB는 서버리스 제품이며 DynamoDB와의 최고 수준의 상호작용은 테이블 수준에서 이뤄집니다. 프로비저닝된 용량 모드에서는 이 수준에서 읽기 및 쓰기 요청 단위를 프로비저닝하고, 리전 및 복제를 선택하고, 백업을 관리합니다. Bigtable은 서버리스 제품이 아닙니다. 하나 이상의 클러스터를 사용해서 인스턴스를 만들어야 하며, 용량은 포함된 노드 수에 따라 결정됩니다. 이러한 리소스에 대한 자세한 내용은 인스턴스, 클러스터, 노드를 참조하세요.

다음 표에서는 DynamoDB 및 Bigtable의 제어 영역 리소스를 비교해서 보여줍니다.

DynamoDB	Bigtable
테이블: 정의된 기본 키가 포함된 항목의 컬렉션입니다. 테이블에는 백업, 복제, 용량에 대한 설정이 포함됩니다.	인스턴스: 복제 및 연결 라우팅이 수행되는 여러 다른 Google Cloud 영역 또는 리전의 Bigtable 클러스터 그룹입니다. 복제 정책은 인스턴스 수준에서 설정됩니다. 클러스터: 동일한 지리적 Google Cloud 영역에 있는 노드 그룹이며, 지연 시간 및 복제를 이유로 애플리케이션 서버와 같은 위치에 배치되는 것이 좋습니다. 용량은 각 클러스터에서 노드 수를 조정하여 관리됩니다. 테이블: row key로 색인이 생성되고 논리적으로 구성된 값입니다. 백업은 테이블 수준에서 제어됩니다.
읽기 용량 단위(RCU) 및 쓰기 용량 단위(WCU): 고정된 페이로드 크기를 사용해서 초당 읽기 또는 쓰기를 허용하는 단위입니다. 페이로드 크기가 더 큰 각 작업에 대해 읽기 또는 쓰기 단위의 비용이 청구됩니다. `UpdateItem` 작업은 업데이트에 항목의 속성 중 일부가 포함된 경우에도 업데이트 이전 또는 이후에 업데이트된 항목의 최대 크기에 사용되는 쓰기 용량을 소비합니다.	노드: 데이터 읽기 및 쓰기를 담당하는 가상 컴퓨팅 리소스입니다. 클러스터에 포함된 노드 수에 따라 읽기, 쓰기, 스캔 처리량이 제한됩니다. 지연 시간 목표, 요청 수, 페이로드 크기 조합에 따라 노드 수를 조정할 수 있습니다. SSD 노드는 RCU 및 WCU 사이의 상당한 차이와 달리 읽기 및 쓰기에 대해 동일한 처리량을 제공합니다. 자세한 내용은 일반적인 워크로드 성능을 참조하세요.
파티션: 노드와 함께 배치된 솔리드 스테이트 드라이브(SSD)에서 지원되는 연속된 행 블록입니다. 각 파티션은 WCU 1,000, RCU 3,000, 데이터 10GB로 엄격하게 제한됩니다.	태블릿: 선택한 스토리지 미디어(SSD 또는 HDD)로 지원되는 연속된 행 블록입니다. 테이블은 워크로드 균형 조정을 위해 태블릿으로 샤딩됩니다. 태블릿은 Bigtable의 노드에 저장되지 않으며, 오히려 Google의 분산 파일 시스템에 저장되어, 확장 시 빠른 데이터 재배포를 가능하게 하며, 여러 복사본을 유지보수하여 추가적인 내구성을 제공합니다.
전역 테이블: 여러 리전 간에 데이터 변경사항을 자동으로 전파하여 데이터 가용성 및 내구성을 늘리는 방법입니다.	복제: 여러 리전 간에 또는 동일 리전 내의 여러 영역 간에 데이터 변경사항을 자동으로 전파하여 데이터 가용성 및 내구성을 늘리는 방법입니다.
해당 사항 없음(N/A)	애플리케이션 프로필: 클라이언트 API 호출을 인스턴스의 적절한 클러스터로 라우팅하는 방법을 Bigtable에 알려주는 설정입니다. 또한 기여 분석을 위해 측정항목을 세분화하기 위한 태그로 앱 프로필을 사용할 수도 있습니다.

지리적 복제

복제는 다음과 같은 고객 요구사항을 지원하기 위해 사용됩니다.

영역 또는 리전 오류가 발생한 경우 비즈니스 연속성을 위한 고가용성
전 세계 어디에서나 데이터 제공 지연 시간을 줄이기 위해 최종 사용자와 근접한 위치에 서비스 데이터 배치
한 클러스터에서 일괄 워크로드를 구현하고 서빙 클러스터에 복제에 의존하기 위해 필요한 경우의 워크로드 격리

Bigtable은 Bigtable을 사용할 수 있는 최대 8개의 Google Cloud 리전에서 사용 가능한 영역에서 복제된 클러스터를 지원합니다. 대부분의 리전에는 영역이 3개 있습니다. Bigtable은 다중 기본 토폴로지의 클러스터 간에 데이터를 자동으로 복제합니다. 즉, 어떤 클러스터에 대해서도 읽기 및 쓰기를 수행할 수 있습니다. Bigtable 복제는 eventual consistency를 갖습니다. 자세한 내용은 복제 개요를 참조하세요.

DynamoDB는 여러 리전 간의 테이블 복제를 지원하기 위해 전역 테이블을 제공합니다. 전역 테이블은 다중 기본 위치를 지원하며 리전 간에 자동으로 복제됩니다. 복제는 eventual consistency를 갖습니다.

다음 표에서는 복제 개념을 보여주고 DynamoDB 및 Bigtable에서 해당 개념이 어떻게 지원되는지 설명합니다.

속성	DynamoDB	Bigtable
다중 기본 복제	예. 모든 전역 테이블에 읽기 및 쓰기를 수행할 수 있습니다.	예. Bigtable 클러스터에 읽기 및 쓰기를 수행할 수 있습니다.
일관성 모델	eventual consistency를 갖습니다. 전역 테이블의 리전 수준에서 읽기 쓰기 일관성을 갖습니다.	eventual consistency를 갖습니다. 모든 테이블의 리전 수준에서 읽기 쓰기 일관성을 갖습니다.
복제 지연 시간	서비스수준계약(SLA)이 없습니다. 초	SLA가 없습니다. 초
구성 세부사항	테이블 수준	인스턴스 수준 인스턴스에 여러 테이블이 포함될 수 있습니다.
구현	선택한 각 리전에서 테이블 복제본을 사용하여 전역 테이블을 만듭니다. 리전 수준 테이블을 전역 테이블로 변환하여 복제본 간에 복제를 자동화합니다. 항목의 신규 및 이전 이미지를 모두 포함하는 스트림을 사용해서 테이블에 DynamoDB 스트림을 사용 설정해야 합니다. 리전의 전역 테이블을 삭제하려면 해당 리전을 삭제합니다.	클러스터가 2개 이상 있는 인스턴스를 만듭니다. 인스턴스의 클러스터 간에 복제가 자동으로 수행됩니다. 영역 수준 Bigtable 인스턴스에서 클러스터를 추가 및 삭제합니다.
복제 옵션	테이블별	인스턴스별
트래픽 라우팅 및 가용성	가장 가까운 지리적 복제본에 트래픽이 라우팅됩니다. 오류 발생 시 커스텀 비즈니스 로직을 사용해서 다른 리전으로 요청을 리디렉션해야 하는지 결정합니다.	애플리케이션 프로필을 사용해서 클러스터 트래픽 라우팅 정책을 구성합니다. 멀티 클러스터 라우팅을 사용해서 가장 가까운 정상 클러스터로 트래픽을 자동으로 라우팅합니다. 오류 발생 시 Bigtable은 HA를 위해 클러스터 간 자동 장애 조치를 지원합니다.
확장	복제된 쓰기 요청 단위(R-WRU)의 쓰기 용량이 복제본 간에 동기화됩니다. 복제된 읽기 요청 단위(R-RCU)의 읽기 용량은 복제본별로 적용됩니다.	필요에 따라 각 복제된 클러스터에서 노드를 추가 또는 삭제하여 클러스터를 개별적으로 확장할 수 있습니다.
비용	R-WRU는 일반적인 WRU보다 비용이 50% 더 듭니다.	각 클러스터의 노드 및 스토리지에 대해 요금이 청구됩니다. 영역 간 리전 복제에는 네트워크 복제 비용이 발생하지 않습니다. 리전 또는 대륙 간에 복제가 수행될 때 비용이 발생합니다.
SLA	99.999%	99.999%

데이터 영역

다음 표에서는 DynamoDB 및 Bigtable의 데이터 모델 개념을 비교해서 보여줍니다. 표의 각 행은 유사한 특징을 설명합니다. 예를 들어 DynamoDB의 항목은 Bigtable의 행과 비슷합니다.

DynamoDB	Bigtable
항목: 다른 모든 항목 중에서 해당 기본 키에 따라 고유하게 식별될 수 있는 속성 그룹입니다. 최대 허용 크기는 400KB입니다.	행: row key로 식별되는 단일 항목입니다. 최대 허용 크기는 256MB입니다.
해당 사항 없음	column family: 열을 그룹화하는 사용자 지정된 네임스페이스입니다.
속성: 이름과 값을 그룹으로 묶은 것입니다. 속성 값은 스칼라, 집합, 문서 유형일 수 있습니다. 속성 크기 자체에는 명시적 한도가 없습니다. 하지만 각 항목이 400KB로 제한되기 때문에 속성이 하나만 있는 항목의 경우 속성 크기는 최대 400KB에서 속성 이름이 차지하는 크기를 뺀 값으로 지정될 수 있습니다.	column qualifier: 열의 column family 내에 있는 고유 식별자입니다. 열의 전체 식별자는 column-family:column-qualifier로 표시됩니다. column qualifier는 column family 내에서 사전순으로 정렬됩니다. column qualifier의 최대 허용 크기는 16KB입니다. 셀: 셀에는 제공된 행, 열, 타임스탬프에 대한 데이터가 저장됩니다. 셀에는 최대 100MB까지 가능한 하나의 값이 포함됩니다.
기본 키: 테이블에서 한 항목의 고유 식별자입니다. 파티션 키 또는 복합 키일 수 있습니다. 파티션 키: 하나의 속성으로 구성된 단순 기본 키입니다. 이 키에 따라 항목이 배치되는 물리적 파티션이 결정됩니다. 최대 허용 크기는 2KB입니다. 정렬 키: 파티션 내에서 행 순서를 결정하는 키입니다. 최대 허용 크기는 1KB입니다. 복합 키: 2개의 속성, 파티션 키와 정렬 키 또는 범위 속성으로 구성된 기본 키입니다.	row key: 테이블에서 한 항목의 고유 식별자입니다. 일반적으로 값과 구분 기호의 연결로 표시됩니다. 최대 허용 크기는 4KB입니다. column qualifier를 사용하면 DynamoDB의 정렬 키와 동일한 동작을 제공할 수 있습니다. 복합 키는 연결된 row key와 column qualifier를 사용해서 빌드할 수 있습니다. 자세한 내용은 이 문서의 스키마 설계 섹션에 있는 스키마 변환 예시를 참조하세요.
TTL(수명): 항목별 타임스탬프는 항목이 더 이상 필요하지 않은 경우를 결정합니다. 지정된 타임스탬프의 날짜 및 시간이 지나면 쓰기 처리량을 소비하지 않고 테이블에서 항목이 삭제됩니다.	가비지 컬렉션: 셀별 타임스탬프는 항목이 더 이상 필요하지 않은 경우를 결정합니다. 가비지 컬렉션은 압축이라고 부르는 백그라운드 프로세스 중에 만료된 항목을 삭제합니다. 가비지 컬렉션 정책은 column family 수준에서 설정되며 해당 수명 외에도 사용자가 유지보수하려는 버전 수에 따라 항목을 삭제할 수 있습니다. 클러스터 크기를 조정하는 동안 압축 용량을 조정할 필요가 없습니다.

작업

데이터 영역 작업을 통해서는 테이블의 데이터에 대해 만들기, 읽기, 업데이트, 삭제(CRUD) 작업을 수행할 수 있습니다. 다음 표에서는 DynamoDB 및 Bigtable의 비슷한 데이터 영역 작업을 비교해서 보여줍니다.

DynamoDB	Bigtable
`CreateTable`	`CreateTable`
`PutItem` `BatchWriteItem`	`MutateRow` `MutateRows` Bigtable은 쓰기 작업을 삽입/업데이트(upsert)로 처리합니다.
`UpdateItem` 조건부 쓰기 증가 및 감소	`CheckAndMutateRow` `ReadModifyWriteRow` Bigtable은 쓰기 작업을 삽입/업데이트(upsert)로 처리합니다.
`GetItem` `BatchGetItem`, `Query`, `Scan`	``ReadRow`` ``ReadRows``(범위, 프리픽스, 역방향 스캔) Bigtable은 row key 프리픽스, 정규 표현식 패턴, row key 범위 정방향 또는 역방향에 따른 효율적인 스캔을 지원합니다.

데이터 유형

Bigtable과 DynamoDB는 모두 스키마가 없습니다. 열의 존재 또는 데이터 유형에 따른 테이블 전체 적용 없이 쓰기 시에 열을 정의할 수 있습니다. 마찬가지로 제공된 열 또는 속성 데이터 유형은 행 또는 항목마다 다를 수 있습니다. 하지만 DynamoDB 및 Bigtable API는 데이터 유형을 다른 방식으로 처리합니다.

각 DynamoDB 쓰기 요청에는 각 속성에 대한 유형 정의가 포함되며, 이는 읽기 요청에 대한 응답으로 반환됩니다.

Bigtable은 모든 것을 바이트로 취급하며 클라이언트 코드가 유형 및 인코딩을 인식하여 클라이언트가 응답을 올바르게 파싱할 수 있다고 가정합니다. 값을 64비트 big-endian 부호 있는 정수로 해석하는 증분 작업은 예외입니다.

다음 표에서는 DynamoDB와 Bigtable 사이의 데이터 유형 차이를 비교해서 보여줍니다.

DynamoDB	Bigtable
스칼라 유형: 서버 응답에서 데이터 유형 설명자 토큰으로 반환됩니다.	바이트: 바이트는 클라이언트 애플리케이션에서 의도한 유형으로 변환됩니다. 증분은 값을 64비트 big-endian 부호 있는 정수로 해석합니다.
집합: 고유 요소의 정렬되지 않은 컬렉션입니다.	column family: column qualifier를 집합 멤버 이름으로 사용할 수 있고, 각 항목에 대해 단일 0바이트를 셀 값으로 제공할 수 있습니다. 집합 멤버는 column family 내에서 사전순으로 정렬됩니다.
맵: 고유 키가 포함된 키-값 쌍의 정렬되지 않은 컬렉션입니다.	column family column qualifier를 맵 키 및 셀 값으로 사용합니다. 맵 키는 사전순으로 정렬됩니다.
목록: 정렬된 항목 컬렉션입니다.	column qualifier 삽입 타임스탬프를 사용하여 list_append와 상응하는 동작을 얻을 수 있으며 추가를 위한 삽입 타임스탬프의 역방향을 사용합니다.

스키마 설계

스키마 설계 시 중요한 고려 사항은 데이터의 저장 방식입니다. Bigtable과 DynamoDB 사이의 주요 차이점은 다음을 처리하는 방식에 있습니다.

단일 값 업데이트
데이터 정렬
데이터 버전 관리
큰 값의 스토리지

단일 값 업데이트

DynamoDB에서 UpdateItem 작업에는 업데이트에 항목 속성의 일부가 포함된 경우에도 "이전" 및 "이후" 항목 크기 중에서 큰 값에 대한 쓰기 용량이 소비됩니다. 즉, DynamoDB에서는 논리적으로 다른 열과 동일한 행에 포함된 경우에도 개별 행에 자주 업데이트되는 열을 배치할 수 있습니다.

Bigtable은 제공된 행의 유일한 열인지 또는 수천 개 중 하나인지에 관계없이 셀을 효율적으로 업데이트할 수 있습니다. 자세한 내용은 단순 쓰기를 참조하세요.

데이터 정렬

DynamoDB는 파티션 키를 해싱하고 무작위로 배포하지만, Bigtable은 row key에 따라 사전순으로 행을 정렬하고 해싱은 사용자에게 남겨둡니다.

일부 액세스 패턴의 경우에는 무작위 키 배포가 최적이 아닙니다. 핫 행 범위 위험을 줄여주지만 파티션 경계를 벗어나는 스캔이 포함된 액세스 패턴의 비용을 높이고 효율성을 낮춥니다. 이러한 무제한 스캔은 특히 시간 측정기준이 포함된 사용 사례의 경우에 일반적입니다.

DynamoDB에서는 파티션 경계를 벗어나는 스캔과 같은 이 유형의 액세스 패턴을 처리하기 위해 보조 색인이 필요하지만 Bigtable은 보조 색인 없이 이를 처리합니다. 마찬가지로 DynamoDB에서는 쿼리 및 스캔 작업이 스캔한 데이터 1MB로 제한되어 이 한도를 벗어나는 페이지로 나누기가 필요합니다. Bigtable에는 이러한 제한이 없습니다.

무작위로 배포된 파티션 키에도 불구하고 DynamoDB는 여전히 핫 파티션을 가질 수 있으며, 선택한 파티션 키가 트래픽을 균일하게 배포하지 않아서 처리량에 부정적 영향을 줄 수 있습니다. 이 문제를 해결하기 위해 DynamoDB에서는 여러 논리적 파티션 키 값 사이에 쓰기를 무작위로 분할하는 쓰기 샤딩이 권장됩니다.

이 설계 패턴을 적용하기 위해서는 고정 집합으로부터 난수를 만들고(예: 1~10) 이 숫자를 논리적 파티션 키로 사용해야 합니다. 파티션 키를 난수화하기 때문에 테이블에 쓰기가 모든 파티션 키 값 사이에 고르게 분산됩니다.

Bigtable에서는 이 절차를 키 솔팅이라고 부르며 핫 태블릿을 방지하기 위한 효과적인 방법으로 사용될 수 있습니다.

데이터 버전 관리

각 Bigtable 셀에는 타임스탬프가 포함되며 항상 최근의 타임스탬프가 제공된 열의 기본값이 됩니다. 타임스탬프의 일반적인 사용 사례는 버전 관리입니다. 버전 관리에서는 타임스탬프에 따라 행 및 열의 이전 데이터 버전과 차별화된 열에 새 셀을 기록합니다.

DynamoDB는 이러한 개념이 없으며 버전 관리를 지원하기 위해 복잡한 스키마 설계가 필요합니다. 이 방법을 위해서는 각 항목의 복사본을 2개 만들어야 합니다. 하나의 복사본은 정렬 키의 시작 부분에서 v0_과 같이 버전 번호 프리픽스가 0이고, 다른 복사본은 v1_과 같이 버전 번호 프리픽스가 1입니다. 항목이 업데이트될 때마다 업데이트된 버전의 정렬 키에서 그 다음으로 높은 버전 프리픽스를 사용하고, 업데이트된 콘텐츠를 버전 프리픽스가 0인 항목에 복사합니다. 이렇게 하면 0 프리픽스를 사용해서 항목의 최신 버전을 찾을 수 있습니다. 이 전략은 각 쓰기 작업에 이전 값 읽기와 2번의 쓰기가 필요하기 때문에 애플리케이션 측면에서 논리를 유지보수해야 할 뿐만 아니라 데이터 쓰기 비용이 증가하고 속도가 느려집니다.

다중 행 트랜잭션과 큰 행 용량 비교

Bigtable은 다중 행 트랜잭션을 지원하지 않습니다. 그러나 DynamoDB에서 사용할 수 있는 항목보다 훨씬 큰 행을 저장할 수 있기 때문에 공유된 row key에 따라 관련 항목을 그룹화하도록 스키마를 설계하여 의도한 트랜잭션 기능을 얻을 수 있는 경우가 많습니다. 이 접근 방법을 보여주는 예시는 단일 테이블 설계 패턴을 참조하세요.

큰 값 저장

Bigtable의 행과 유사한 DynamoDB 항목이 400KB로 제한되기 때문에 큰 값을 저장하기 위해서는 항목 간에 값을 분할하거나 S3와 같은 다른 미디어에 저장해야 합니다. 두 가지 방법 모두 애플리케이션에 복잡성이 추가됩니다. 반면에 Bigtable 셀은 최대 100MB까지 저장이 가능하고, Bigtable 행은 최대 256MB까지 저장이 가능합니다.

스키마 변환 예시

이 섹션의 예시에서는 주요 스키마 설계 차이를 염두에 두고 DynamoDB에서 Bigtable로 스키마를 변환합니다.

기본 스키마 마이그레이션

제품 카탈로그는 기본 키-값 패턴을 보여주는 좋은 예시입니다. 다음은 DynamoDB에서 스키마의 모습을 보여줍니다.

기본 키		속성
파티션 키	정렬 키	설명	가격	미리보기 이미지
hats	fedoras#brandA	프리미엄 양모로 제작...	30	https://storage…
hats	fedoras#brandB	내구성이 우수한 방수 캔버스 재질...	28	https://storage…
hats	newsboy#brandB	일상에 빈티지한 매력을 더하는...	25	https://storage…
shoes	sneakers#brandA	스타일과 편안함을 동시에 추구하는...	40	https://storage…
shoes	sneakers#brandB	현대적인 재료로 클래식 감성을 더하는...	50	https://storage…

이 테이블에서 DynamoDB에서 Bigtable로의 매핑은 직관적으로 수행됩니다. DynamoDB의 복합 기본 키를 복합 Bigtable row key로 변환합니다. 동일한 열 집합이 포함된 하나의 column family(SKU)를 만듭니다.

	SKU
row key	설명	가격	미리보기 이미지
hats#fedoras#brandA	프리미엄 양모로 제작...	30	https://storage…
hats#fedoras#brandB	내구성이 우수한 방수 캔버스 재질...	28	https://storage…
hats#newsboy#brandB	일상에 빈티지한 매력을 더하는...	25	https://storage…
shoes#sneakers#brandA	스타일과 편안함을 동시에 추구하는...	40	https://storage…
shoes#sneakers#brandB	현대적인 재료로 클래식 감성을 더하는...	50	https://storage…

단일 테이블 설계 패턴

단일 테이블 설계 패턴은 관계형 데이터베이스에서 여러 테이블로 표시되는 항목을 DynamoDB의 단일 테이블로 가져옵니다. 이전 예시의 접근 방식을 사용해서 이 스키마를 Bigtable에 있는 것처럼 복제할 수 있습니다. 하지만 프로세스에서 스키마 문제를 해결하는 것이 더 좋습니다.

이 스키마에서 파티션 키에는 더 빠른 액세스를 위해 해당 동영상과 관련된 모든 속성을 함께 배치하는 데 도움이 되는 동영상에 대한 고유 ID가 포함되어 있습니다. DynamoDB의 항목 크기 제한에 따라 단일 행에서 자유 텍스트 댓글을 무제한으로 입력할 수 없습니다. 따라서 파티션 내에서 각 댓글을 사전의 역순으로 정렬된 별도의 행으로 만들기 위해 VideoComment#reverse-timestamp 패턴의 정렬 키가 사용됩니다.

이 동영상에 댓글이 500개 있고 소유자가 동영상을 삭제하길 원한다고 가정해 보세요. 즉, 모든 댓글과 동영상 속성도 삭제해야 합니다. DynamoDB에서 이를 수행하려면 파티션 내에서 모든 키를 스캔하고 여러 삭제 요청을 실행해서 각 항목을 반복 처리해야 합니다. DynamoDB는 다중 행 트랜잭션을 지원하지만 이 삭제 요청은 단일 트랜잭션에서 수행하기에 너무 큽니다.

기본 키		속성
파티션 키	정렬 키	UploadDate	형식
0123	동영상	2023-09-10T15:21:48	{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"}
	VideoComment#98765481	Content
	VideoComment#98765481	좋아요. 특수 효과가 놀라워요.
	VideoComment#86751345	Content
	VideoComment#86751345	1:05에 오디오 문제가 있어 보여요.
	VideoStatsLikes	Count
	VideoStatsLikes	3
	VideoStatsViews	Count
	VideoStatsViews	156
0124	동영상	2023-09-10T17:03:21	{"480": "https://storage…", "720": "https://storage…"}
	VideoComment#97531849	Content
	VideoComment#97531849	친구들과 모두 공유했어요.
	VideoComment#87616471	Content
	VideoComment#87616471	스타일을 보면 영화 감독이 떠오르는 데 정확히 누군지 잘 모르겠어요.
	VideoStats	ViewCount
	VideoStats	45

코드를 단순화하고 데이터 요청을 더 빠르게 처리하고 비용을 낮출 수 있도록 마이그레이션할 때 이 스키마를 수정합니다. Bigtable 행은 DynamoDB 항목보다 훨씬 큰 용량을 포함하며 많은 수의 댓글을 처리할 수 있습니다. 동영상에 수백만 개의 댓글이 달릴 수 있는 경우를 처리하기 위해서는 고정된 개수의 최신 댓글만 유지하도록 가비지 컬렉션 정책을 설정할 수 있습니다.

전체 행을 업데이트하는 오버헤드 없이 카운터를 업데이트할 수 있으므로 이를 분할할 필요가 없습니다. Bigtable 타임스탬프는 자동으로 사전의 역순으로 정렬된 댓글을 제공하기 때문에 UploadDate 열을 사용하거나 역방향 타임스탬프를 계산하고 정렬 키를 만들 필요가 없습니다. 따라서 스키마가 크게 단순화되고, 동영상이 삭제될 경우 모든 댓글을 포함하여 동영상 행을 단일 요청으로 트랜잭션에 따라 삭제할 수 있습니다.

마지막으로, 최적화를 위해 Bigtable의 열이 사전순으로 정렬되기 때문에 단일 읽기 요청에서 동영상 속성부터 최상위 N개의 최근 댓글까지 범위를 빠르게 스캔할 수 있는 방식으로 열 이름을 바꿀 수 있습니다. 이렇게 동영상이 로드될 때 수행하길 원하는 작업을 수행할 수 있습니다. 그런 후 시청자가 스크롤할 때 나머지 댓글을 페이지로 표시할 수 있습니다.

	속성
row key	형식	좋아요 수	뷰	UserComments
0123	{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"} @2023-09-10T15:21:48	3	156	좋아요. 특수 효과가 놀라워요. @ 2023-09-10T19:01:15 1:05에 오디오 문제가 있어 보여요. @ 2023-09-10T16:30:42
0124	{"480": "https://storage…", "720":"https://storage…"} @2023-09-10T17:03:21		45	스타일을 보면 영화 감독이 떠오르는 데 정확히 누군지 잘 모르겠어요. @2023-10-12T07:08:51

인접 목록 설계 패턴

DynamoDB에서 인접 목록 설계 패턴이라고도 부르는 이 설계의 약간 다른 버전을 고려해 보겠습니다.

기본 키		속성
파티션 키	정렬 키	DateCreated	세부정보
Invoice-0123	Invoice-0123	2023-09-10T15:21:48	{"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."}
	Payment-0680	2023-09-10T15:21:40	{"amount_usd": 120, "bill_to":"John…", "address":"123 Abc St…"}
	Payment-0789	2023-09-10T15:21:31	{"amount_usd": 120, "bill_to":"Jane…", "address":"13 Xyz St…"}
Invoice-0124	Invoice-0124	2023-09-09T10:11:28	{"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."}
	Payment-0327	2023-09-09T10:11:10	{"amount_usd": 180, "bill_to":"Bob…", "address":"321 Cba St…"}
	Payment-0275	2023-09-09T10:11:03	{"amount_usd": 70, "bill_to":"Kate…", "address":"21 Zyx St…"}

이 테이블에서 정렬 키는 시간 대신 결제 ID를 기반으로 하므로, 다른 열 전체 패턴을 사용할 수 있으며, 이러한 ID를 Bigtable에서 별개의 열로 만들 수 있습니다. 이렇게 하면 이전 예시와 비슷한 이점이 있습니다.

	인보이스	결제
row key	세부정보	0680	0789
0123	{"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."} @ 2023-09-10T15:21:48	{"amount_usd": 120, "bill_to":"John…", "address":"123 Abc St…"} @ 2023-09-10T15:21:40	{"amount_usd": 120, "bill_to":"Jane…", "address":"13 Xyz St…"} @ 2023-09-10T15:21:31
row key	세부정보	0275	0327
0124	{"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."} @ 2023-09-09T10:11:28	{"amount_usd": 70, "bill_to":"Kate…", "address":"21 Zyx St…"} @ 2023-09-09T10:11:03	{"amount_usd": 180, "bill_to":"Bob…", "address":"321 Cba St…"} @ 2023-09-09T10:11:10

이전 예시에 표시된 것처럼 올바른 스키마 설계를 사용할 경우 Bigtable의 전체 열 모델은 매우 강력할 수 있으며, 비용이 높은 다중 행 트랜잭션, 보조 색인 설정, 다른 데이터베이스의 삭제 시 연계 동작이 필요할 수 있는 많은 사용 사례를 지원할 수 있습니다.

다음 단계

Bigtable 스키마 디자인 읽어보기
Bigtable 에뮬레이터 알아보기
Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴보세요. Cloud 아키텍처 센터 살펴보기