스키마 설계 권장사항

이 페이지에는 Bigtable 스키마 설계에 대한 정보가 포함되어 있습니다. 이 페이지를 읽기 전에 Bigtable 개요를 숙지해야 합니다. 이 페이지에서는 다음 주제를 다룹니다.

• 일반 개념: 스키마를 설계할 때 유의해야 할 기본 개념입니다.
• 권장사항: 테이블 구성요소별로 분류된 대부분의 사용 사례에 적용되는 설계 가이드라인입니다.
• 특수 사용 사례: 일부 특정 사용 사례와 데이터 패턴에 대한 권장사항입니다.

일반적인 개념

Bigtable 스키마 설계는 관계형 데이터베이스 스키마 설계와 다릅니다. Bigtable 스키마는 스키마 정의 객체 또는 파일이 아닌 애플리케이션 논리에 따라 정의됩니다. 테이블을 만들거나 업데이트할 때 테이블에 column family를 추가할 수 있지만 열 및 row key 패턴은 테이블에 기록하는 데이터에 의해 정의됩니다.

Bigtable에서 스키마는 다음 테이블 구성요소 구조를 포함한 테이블의 청사진이나 모델입니다.

• Row key
• 가비지 컬렉션 정책이 포함된 column family
• 열

요점: 사용할 쿼리에 대한 스키마를 설계합니다.

Bigtable에서 스키마 설계는 주로 테이블에 전송하려는 쿼리 또는 읽기 요청에 따라 결정됩니다. 행 범위 읽기가 Bigtable 데이터를 읽는 가장 빠른 방법이므로 이 페이지의 권장사항은 행 범위 읽기를 최적화할 수 있도록 설계되었습니다. 대부분의 경우 row key 프리픽스를 기반으로 쿼리를 전송합니다.

두 번째 고려사항은 핫스팟을 방지하는 것입니다. 핫스팟을 방지하려면 쓰기 패턴을 고려해야 하며 짧은 시간 내에 작은 키 공간에 액세스하지 않는 방법을 고려해야 합니다.

Bigtable 스키마 설계에는 다음과 같은 일반적인 개념이 적용됩니다.

• Bigtable은 관계형 저장소가 아닌 키/값 저장소입니다. 조인을 지원하지 않으며 트랜잭션은 단일 행 내에서만 지원됩니다.
• 각 테이블에는 row key에 해당하는 하나의 색인만 있습니다. 보조 색인은 없습니다. 각 row key는 고유해야 합니다.
• 행은 row key에 따라 사전순으로 정렬됩니다(가장 낮은 바이트 문자열에서 가장 높은 바이트 문자열의 순서로). row key는 알파벳 순서의 바이너리에 해당하는 빅 엔디안 바이트 순서(네트워크 바이트 순서라고도 함)로 정렬됩니다.
• column family는 특정 순서로 저장되지 않습니다.
• 열은 column family로 그룹화되며 column family 내에서 사전순으로 정렬됩니다. 예를 들어 ProcessName, User, %CPU, ID, Memory, DiskRead, Priority의 column qualifier가 있는 SysMonitor라는 column family에서 Bigtable은 다음 순서로 열을 저장합니다.

			SysMonitor
%CPU	DiskRead	ID	메모리	우선순위	ProcessName	사용자

• 행과 열의 교차 부분에 타임스탬프가 적용된 셀 여러 개가 포함될 수 있습니다. 각 셀에는 행과 열에 대한 타임스탬프가 적용된 고유한 버전의 데이터가 포함됩니다.
• 집계 column family에는 집계 셀이 포함됩니다. 집계 셀만 포함된 column family를 만들 수 있습니다. 집계를 사용하면 새 데이터를 이미 셀에 있는 데이터와 병합할 수 있습니다.
• 모든 작업은 행 수준에서 원자적으로 이루어집니다. 작업은 전체 행에 영향을 미치거나 어떠한 행에도 영향을 미치지 않습니다.
• 테이블의 행 공간 전반에 읽기와 쓰기 모두를 고르게 분산해야 합니다.
• Bigtable 테이블은 희소 테이블입니다. 열은 열을 사용하지 않는 행의 공간을 차지하지 않습니다.

권장사항

스키마를 올바르게 설계하면 성능과 확장성이 향상되지만 잘못 설계하면 시스템 성능이 저하될 수 있습니다. 모든 사용 사례는 각기 다르며 자체 설계가 필요하지만 대부분의 사용 사례에 다음과 같은 권장사항이 적용됩니다. 예외는 명시되어 있습니다.

다음 섹션에서는 테이블 수준부터 row key 수준까지 스키마 설계의 권장사항을 설명합니다.

• 테이블
• column family
• 열
• 행
• 셀
• Row key

모든 테이블 요소, 특히 row key는 계획된 읽기 요청을 염두에 두고 설계되어야 합니다. 할당량 및 한도에서 모든 테이블 요소의 권장 및 엄격한 크기 한도를 확인하세요.

인스턴스의 모든 테이블은 동일한 태블릿에 저장되므로 한 테이블의 핫스팟을 초래하는 스키마 설계는 동일한 인스턴스에 있는 다른 테이블의 지연 시간에 영향을 줄 수 있습니다. 핫스팟은 단기간에 테이블의 한 부분에 자주 액세스하므로 발생합니다.

테이블

별도의 테이블이 아닌 같은 테이블에 유사한 스키마가 있는 데이터 세트를 저장합니다.

다른 데이터베이스 시스템에서는 제목과 열 수에 따라 여러 테이블에 데이터를 저장할 수 있습니다. 그러나 Bigtable에서는 일반적으로 모든 데이터를 하나의 테이블에 저장하는 것이 좋습니다. 각 데이터 세트에 사용할 고유한 row key 프리픽스를 할당할 수 있습니다. 그러면 Bigtable에서 관련 데이터를 연속 행 범위에 저장하므로 row key 프리픽스로 쿼리할 수 있습니다.

Bigtable에서 테이블은 인스턴스당 1,000개로 제한되지만 다음과 같은 이유로 많은 수의 테이블을 만들지 않는 것이 좋습니다.

• 요청을 여러 테이블에 전송하면 백엔드 연결 오버헤드가 증가하여 꼬리 지연 시간이 늘어날 수 있습니다.
• 테이블을 더 만들면 부하 분산이 개선되지 않으며 관리 오버헤드가 증가할 수 있습니다.

다른 스키마가 필요한 사용 사례마다 별도의 테이블을 원할 수 있지만 유사한 데이터에는 별도의 테이블을 사용해서는 안 됩니다. 예를 들어 새해가 되거나 신규 고객이 있다고 해서 새 테이블을 만들면 안 됩니다.

column family

관련 열을 동일한 column family에 삽입합니다. 행 하나에 서로 관련된 값이 여러 개 포함된 경우 같은 이 값이 column family에 포함된 열을 그룹화하는 것이 좋습니다. 복잡한 필터를 설계할 필요가 없도록 데이터를 최대한 가깝게 그룹화하면 자주 사용하는 읽기 요청에서 필요한 정보만 가져옵니다.

column family를 테이블당 최대 100개까지 만듭니다. column family를 100개 초과하여 만들면 성능이 저하될 수 있습니다.

column family의 닉네임을 선택합니다. 이름은 각 요청에 전송되는 데이터에 포함됩니다.

데이터 보관 요구사항이 다른 열을 다른 column family에 넣습니다. 이는 스토리지 비용을 제한하려는 경우에 중요합니다. 가비지 컬렉션 정책은 열 수준이 아닌 column family 수준에서 설정됩니다. 예를 들어 특정 데이터 중 최신 버전만 유지해야 하는 경우 해당 항목 버전 1,000개를 저장하도록 설정된 column family에 저장하지 마세요. 그렇지 않은 경우 불필요한 데이터 999 셀을 저장하는 비용을 지불하게 됩니다.

열

테이블에 필요한 만큼 열을 만듭니다. Bigtable 테이블은 희소하며 행에서 사용되지 않는 열에 대한 공간 패널티는 없습니다. 행당 최대 한도인 256MB를 초과하지 않는 한 테이블에 열 수백만 개를 포함할 수 있습니다.

단일 행에 열을 너무 많이 사용하지 마세요. 테이블에 열 수백만 개가 포함될 수 있지만 행은 그렇지 않아야 합니다. 이 권장사항은 다음과 같은 몇 가지 요인에 영향을 줍니다.

• Bigtable이 행에서 각 셀을 처리하려면 시간이 걸립니다.
• 각 셀은 테이블에 저장되고 네트워크를 통해 전송되는 데이터 양에 더 많은 오버헤드를 줍니다. 예를 들어 데이터 1KB(1,024바이트)를 저장하는 경우 각각 1바이트를 포함하는 셀 1,024개 전체에 데이터를 분산시키는 것보다 데이터를 단일 셀에 저장하는 것이 훨씬 더 공간 효율적입니다.

데이터 세트에서 Bigtable이 효율적으로 처리할 수 있는 행보다 더 많은 열이 논리적으로 필요하면 데이터를 단일 열에 protobuf로 저장하는 것이 좋습니다.

원하는 경우 column qualifier를 데이터로 취급할 수 있습니다. 모든 열에 column qualifier를 저장해야 하므로 열 이름을 값으로 지정하면 공간을 절약할 수 있습니다. 예를 들어 우정에 대한 데이터를 Friends column family에 저장하는 테이블을 가정해 보겠습니다. 각 행은 사람과 모든 우정을 나타냅니다. 각 column qualifier는 친구 ID가 될 수 있습니다. 그러면 해당 행의 각 열에 대한 값은 친구가 있는 소셜 서클일 수 있습니다. 이 예시에서 행은 다음과 같이 표시될 수 있습니다.

row key	프레드	Gabriel	히로시	서윤	Jakob
호세	독서 클럽	직장	테니스
소피아			직장	학교	체스 클럽

이 스키마를 column qualifier를 데이터로 취급하지 않는 동일한 데이터의 스키마와 대조합니다. 대신 모든 행에 동일한 열이 포함됩니다.

row key	친구	원
호세#1	프레드	독서 클럽
호세#2	Gabriel	직장
호세#3	히로시	테니스
소피아#1	히로시	직장
소피아#2	서윤	학교
소피아#3	Jakob	체스 클럽

두 번째 스키마 설계로 인해 테이블이 훨씬 빠르게 증가합니다.

column qualifier를 사용하여 데이터를 저장하는 경우 column qualifier를 짧고 의미 있는 이름으로 지정합니다. 이 방식을 사용하면 각 요청에 대해 전송되는 데이터 양을 줄일 수 있습니다. 최대 크기는 16KB입니다.

행

단일 행에 있는 모든 값의 크기를 100MB 미만으로 유지합니다. 단일 행의 데이터를 256MB 이하로 유지합니다. 이 한도를 초과하는 행은 읽기 성능을 저하시킬 수 있습니다.

항목의 모든 정보를 단일 행에 유지합니다. 대부분의 사용 사례에서 불일치를 방지하려면 원자적으로 또는 전부 한꺼번에 읽어야 하는 데이터를 행 1개 이상에 저장하지 마세요. 예를 들어 테이블에서 행 두 개를 업데이트하는 경우 한 행은 성공적으로 업데이트되고 다른 행은 업데이트되지 못할 수 있습니다. 관련 데이터가 정확하려면 스키마에 행 두 개 이상이 동시에 업데이트되지 않아야 합니다. 이렇게 하면 쓰기 요청의 일부가 실패하거나 다시 전송되어야 하는 경우 해당 데이터가 일시적으로 불완전해지는 경우가 없습니다.

예외: 단일 행에 항목을 유지했을 때 크기가 수백 MB가 되면 여러 행에 데이터를 분할해야 합니다.

관련 항목을 인접 행에 저장하면 더욱 효율적으로 읽을 수 있습니다.

셀

단일 셀에 데이터를 10MB 넘게 저장하지 마세요. 셀은 고유 타임스탬프가 있는 특정 행과 열에 저장된 데이터이며 여러 셀이 행과 열의 교차 부분에 저장될 수 있습니다. 열에 보관된 셀 수에는 해당 열이 포함된 column family에 설정한 가비지 컬렉션 정책이 적용됩니다.

집계 셀을 사용하여 합산 데이터를 저장 및 업데이트하세요. 소매점의 직원당 월별 판매 합계와 같은 항목의 집계된 이벤트 값만 필요한 경우 집계를 사용할 수 있습니다. 자세한 내용은 쓰기 시간에 값 집계를 참조하세요.

Row key

데이터 검색에 사용할 쿼리를 기반으로 row key를 설계합니다. 잘 설계된 row key는 Bigtable에서 최고의 성능을 발휘합니다. 가장 효율적인 Bigtable 쿼리는 다음 중 하나를 사용하여 데이터를 검색합니다.

• row key
• row key 프리픽스
• 시작 및 종료 row key로 정의된 행 범위

다른 유형의 쿼리는 훨씬 비효율적인 전체 테이블 스캔을 트리거합니다. 지금 올바른 row key를 선택하면 나중에 힘든 데이터 마이그레이션 프로세스를 방지할 수 있습니다.

row key를 짧게 유지합니다. row key는 4KB 이하여야 합니다. row key를 길게 만들면 메모리와 스토리지가 더 많이 소모되므로 Bigtable 서버로부터 응답을 받는 데 걸리는 시간이 길어집니다.

구분된 값 여러 개를 각 row key에 저장합니다. Bigtable을 효율적으로 쿼리할 수 있는 최고의 방법은 row key를 사용하는 것이므로 row key에 여러 식별자를 포함하는 것이 유용할 경우가 많습니다. row key에 여러 개의 값이 포함되어 있을 때는 데이터를 어떻게 사용할 것인지를 명확하게 이해하는 것이 특히 중요합니다.

row key 세그먼트는 일반적으로 콜론, 슬래시 또는 해시 기호와 같은 구분 기호로 구분됩니다. 첫 번째 세그먼트나 연속 세그먼트 집합은 row key 프리픽스이며 마지막 세그먼트나 연속 세그먼트 집합은 row key 서픽스입니다.

row key 프리픽스를 잘 계획하면 Bigtable에서 기본 제공하는 정렬 순서를 활용하여 관련 데이터를 연속된 행에 저장할 수 있습니다. 연속된 행에 관련 데이터를 저장하면 비효율적인 테이블 스캔을 실행하지 않고 행 범위로 관련 데이터에 액세스할 수 있습니다.

데이터에 숫자로 저장 또는 정렬하려는 정수가 포함된 경우 앞자리가 0인 정수를 패딩합니다. Bigtable은 데이터를 사전순으로 저장합니다. 예를 들어 사전순으로 20 > 03이 아닌 3 > 20으로 저장합니다. 앞자리가 0인 3을 패딩하면 숫자가 수치적으로 정렬됩니다. 이 방법은 범위 기반 쿼리가 사용되는 타임스탬프에 중요합니다.

잘 정의된 행 범위를 검색할 수 있도록 row key를 만드는 것이 중요합니다. 그렇지 않으면 쿼리에 테이블 스캔이 필요하며 이는 특정 행을 검색하는 것보다 훨씬 느립니다.

예를 들어 애플리케이션에서 휴대기기 데이터를 추적하는 경우 기기 유형, 기기 ID, 데이터가 기록된 날짜로 구성된 row key를 사용할 수 있습니다. 이 데이터의 row key는 다음과 같습니다.

        phone#4c410523#20200501
        phone#4c410523#20200502
        tablet#a0b81f74#20200501
        tablet#a0b81f74#20200502

이 row key 설계를 사용하면 다음에 대한 단일 요청으로 데이터를 검색할 수 있습니다.

• 기기 유형
• 기기 유형 및 기기 ID 조합

특정 날짜의 모든 데이터를 검색하려는 경우에는 이 row key 설계가 적합하지 않습니다. 날짜는 세 번째 세그먼트나 row key 서픽스에 저장되므로 row key 또는 row key의 중간 세그먼트를 기준으로 행 범위를 요청할 수 없습니다. 대신 일 값을 검색하는 전체 테이블을 스캔하는 필터를 사용하여 읽기 요청을 전송해야 합니다.

가능하면 row key에서 인간이 읽을 수 있는 문자열 값을 사용합니다. 이렇게 하면 Key Visualizer 도구를 사용하여 Bigtable 문제를 쉽게 해결할 수 있습니다.

공통 값으로 시작하고 상세 값으로 끝나는 row key를 설계해야 하는 경우가 있습니다. 예를 들어 row key에 대륙, 국가, 도시가 포함된 경우 다음과 같은 row key를 만들어 카디널리티가 낮은 값을 기준으로 자동으로 정렬할 수 있습니다.

        asia#india#bangalore
        asia#india#mumbai
        asia#japan#osaka
        asia#japan#sapporo
        southamerica#bolivia#cochabamba
        southamerica#bolivia#lapaz
        southamerica#chile#santiago
        southamerica#chile#temuco

참고: 프로덕션에서는 아시아의 AS 또는 볼리비아의 591과 같이 스토리지를 적게 차지하는 식별자를 사용하세요.

피해야 할 row key

일부 유형의 row key는 데이터를 쿼리하기 어렵게 만들거나 성능 일부를 저하시킬 수 있습니다. 이 섹션에서는 Bigtable에서 사용하지 말아야 할 몇 가지 유형의 row key에 대해 설명합니다.

타임스탬프로 시작되는 row key. 이렇게 하면 순차적 쓰기가 단일 노드로 푸시되어 핫스팟이 생성됩니다. row key에 타임스탬프를 추가하는 경우 핫스팟을 방지하려면 사용자 ID와 같이 카디널리티가 높은 값을 앞에 추가합니다.

관련 데이터가 그룹화되지 않게 하는 row key. 관련 데이터를 불연속 행 범위에 저장하는 row key를 사용하지 마세요. 함께 읽을 때 효율적이지 않습니다.

순차적 숫자 ID. 시스템에서 각 애플리케이션 사용자에게 숫자 ID를 할당한다고 가정해 보겠습니다. 이때 사용자의 숫자 ID를 테이블의 row key로 사용했으면 하는 생각이 들 수가 있습니다. 하지만 신규 사용자일수록 활동이 많을 가능성이 높기 때문에 이 접근 방식은 대부분의 트래픽을 소수의 노드에 푸시할 확률이 높습니다.

더 안전한 방법은 사용자 숫자 ID의 역방향 버전을 사용하는 것입니다. 그러면 트래픽이 Bigtable 테이블의 모든 노드에 더욱 고르게 분산되기 때문입니다.

자주 업데이트되는 식별자. 자주 업데이트해야 하는 값을 식별하는 데 단일 row key를 사용하지 마세요. 예를 들어 여러 기기에 대한 메모리 사용량 데이터를 1초에 한 번 저장하는 경우 기기 ID와 저장 중인 측정항목(예: 4c410523#memusage)으로 구성된 각 기기에 단일 row key를 사용하지 말고 행을 반복적으로 업데이트합니다. 이러한 유형의 작업은 자주 사용되는 행을 저장하는 태블릿에 과부하를 일으킵니다. 또한 가비지 컬렉션 중에 셀이 삭제될 때까지 열의 이전 값이 공간을 차지하므로 행이 크기 제한을 초과할 수 있습니다.

대신 각 새 읽기를 새 행에 저장합니다. 메모리 사용량 예시를 사용하면 각 row key에 기기 ID, 측정항목 유형, 타임스탬프가 포함될 수 있으므로 row key는 4c410523#memusage#1423523569918과 유사합니다. Bigtable에서는 새 행을 만드는 데 걸리는 시간과 새 셀을 만드는 데 걸리는 시간이 동일하므로 이 전략이 유용합니다. 또한 이 전략을 사용하면 적절한 시작 및 종료 키를 계산함으로써 특정 기간에서 데이터를 빨리 읽을 수 있습니다.

1분마다 수백 번 업데이트되는 카운터와 같이 자주 변경되는 값의 경우에는 데이터를 메모리의 애플리케이션 계층에만 유지하고 새 행을 주기적으로 Bigtable에 쓰는 것이 가장 좋습니다.

해시 처리된 값. row key를 해시 처리하면 Bigtable에서 자연 정렬 순서를 활용할 수 없게 되므로 쿼리에 적합한 방식으로 행을 저장할 수 없게 됩니다. 같은 이유로 값을 해시 처리하면 Key Visualizer 도구를 사용하여 Bigtable의 문제를 해결하기가 어려워집니다. 해싱된 값 대신 인간이 읽을 수 있는 값을 사용하세요.

인간이 읽을 수 있는 문자열이 아닌 원시 바이트로 표현되는 값. 원시 바이트는 열 값에 적합하지만 가독성 및 문제 해결을 위해 row key에 문자열 값을 사용합니다.

특수 사용 사례

Bigtable에 저장하기 위해 스키마를 설계할 때 특별히 고려해야 하는 고유한 데이터 세트가 있을 수 있습니다. 이 섹션에서는 전체가 아닌 서로 다른 유형의 일부 Bigtable 데이터와 이를 가장 적합한 방식으로 저장하는 몇 가지 권장 방법을 설명합니다.

시간 기반 데이터

기록된 시간을 기준으로 데이터를 자주 검색하는 경우 row key에 타임스탬프를 포함할 수 있습니다.

예를 들어 애플리케이션에서 여러 머신에 대해 1초에 한 번씩 CPU 및 메모리 사용량과 같은 성능 관련 데이터를 기록할 수 있습니다. 데이터의 타임스탬프와 머신의 식별자를 결합하여(예: machine_4223421#1425330757685) 이 데이터의 row key를 만들 수 있습니다. row key는 사전적으로 정렬됩니다.

row key에 타임스탬프를 포함하는 경우 타임스탬프 자체 또는 row key의 시작 부분에 타임스탬프를 사용하지 마세요. 이렇게 하면 순차적 쓰기가 단일 노드로 푸시되어 핫스팟이 생성됩니다.

일반적으로 쿼리에서 가장 최근 레코드를 먼저 검색하는 경우 고려할 수 있는 패턴은 row key에 역방향 타임스탬프를 사용하는 것입니다. 이 패턴을 사용하면 행이 최신 행부터 가장 오래된 행 순으로 정렬되므로 좀 더 최근 데이터가 표의 앞쪽에 표시됩니다. 다른 타임스탬프와 마찬가지로 핫스팟이 발생하지 않도록 역순 타임스탬프로 row key를 시작하지 마세요.

긴 정수에 대한 프로그래밍 언어의 최대값(예: 자바 java.lang.Long.MAX_VALUE)에서 타임스탬프를 빼면 역방향 타임스탬프를 가져올 수 있습니다.

참고: 타임스탬프는 일반적으로 1970-01-01 00:00:00 UTC 이후의 마이크로초 수로 표시됩니다.

특히 시계열 데이터 작업에 대한 자세한 내용은 시계열 데이터의 스키마 설계를 참조하세요.

멀티테넌시

row key 프리픽스는 '멀티테넌시 지원' 사용 사례를 위한 확장 가능한 솔루션을 제공합니다. 이 시나리오에서는 다중 클라이언트를 대신해 같은 데이터 모델을 사용하여 비슷한 데이터를 저장합니다. 모든 테넌트에 테이블 하나를 사용하는 것이 멀티 테넌트 데이터를 저장하고 액세스하는 데 가장 효율적인 방법입니다.

예를 들어 여러 회사를 대신해 구매 내역을 저장하고 추적한다고 가정해 봅시다. 각 회사의 고유한 ID를 row key 프리픽스로 사용할 수 있습니다. 테넌트의 모든 데이터는 동일한 테이블의 연속된 행에 저장되며 row key 프리픽스를 사용하여 쿼리하거나 필터링할 수 있습니다. 그러면 한 회사가 더 이상 고객이 아니어서 이 회사를 위해 저장했던 구매 내역 데이터를 삭제해야 하는 경우 이 고객의 row key 프리픽스를 사용하는 행 범위를 삭제하면 됩니다.

예를 들어 altostrat 및 examplepetstore 고객의 휴대전화 데이터를 저장하는 경우 다음과 같은 row key를 만들 수 있습니다. 그런 다음 altostrat이 더 이상 고객이 아니면 row key 프리픽스가 altostrat이 있는 모든 행을 삭제합니다.

        altostrat#phone#4c410523#20190501
        altostrat#phone#4c410523#20190502
        altostrat#tablet#a0b41f74#20190501
        examplepetstore#phone#4c410523#20190502
        examplepetstore#tablet#a6b81f79#20190501
        examplepetstore#tablet#a0b81f79#20190502

반면 각 회사를 대신하여 각 회사의 자체 테이블에 데이터를 저장한다면 성능 및 확장성 문제를 겪을 수 있습니다. 또한 인스턴스당 테이블 1,000개인 Bigtable의 제한에 의도치 않게 도달할 수 있습니다. 인스턴스가 이 한도에 도달하면 Bigtable은 인스턴스에 더 많은 테이블을 만들지 못하도록 합니다.

개인 정보 보호

사용 사례에서 요구하지 않는 한 row key 또는 column family ID에서 개인 식별 정보(PII)나 사용자 데이터를 사용하지 마세요. row key와 column family의 값은 고객 데이터 및 서비스 데이터이며 암호화 또는 로깅과 같이 이를 사용하는 애플리케이션에서 비공개 데이터에 액세스해서는 안되는 사용자에게 이를 실수로 노출할 수 있습니다.

서비스 데이터 처리 방법에 대한 자세한 내용은 Google Cloud 개인정보처리방침을 참조하세요.

도메인 이름

도메인 이름을 Bigtable 데이터로 저장할 수 있습니다.

다양한 도메인 이름

도메인 이름으로 표시할 수 있는 항목의 데이터를 저장할 경우 역방향 도메인 이름(예: com.company.product)을 row key로 사용하는 것이 좋습니다. 역방향 도메인 이름 사용은 각 행의 데이터가 인접한 행과 겹치는 경향이 있는 경우에 매우 유용합니다. 이 경우 Bigtable이 데이터를 더욱 효율적으로 압축할 수 있습니다.

반대로 역전되지 않은 표준 도메인 이름은 관련 데이터가 한 곳에 그룹화되지 않는 방식으로 행을 정렬할 수 있으므로 압축 효율성과 읽기 효율성이 저하될 수 있습니다.

이 접근 방식은 데이터가 여러 역방향 도메인 이름에 흩어져 있을 때 가장 효과적입니다.

이 점을 설명하기 위해 Bigtable에서 사전순으로 자동 정렬한 다음 도메인 이름을 살펴보세요.

      drive.google.com
      en.wikipedia.org
      maps.google.com

이는 google.com의 모든 행을 쿼리하려는 사용 사례에는 적합하지 않습니다. 반대로 도메인 이름이 역전된 같은 행을 사용하는 것이 좋습니다.

      com.google.drive
      com.google.maps
      org.wikipedia.en

두 번째 예시에서 관련 행은 자동으로 행 범위로 간단하게 검색할 수 있도록 자동 정렬됩니다.

도메인 이름이 거의 없음

한 개 또는 적은 수의 도메인 이름에만 많은 데이터를 저장할 경우 row key의 다른 값을 사용하는 것이 좋습니다. 이와 달리 쓰기를 클러스터의 단일 노드에 푸시하면 핫스팟이 발생하거나 행이 너무 커질 수 있습니다.

쿼리 변경 또는 불확실한 쿼리

데이터에서 항상 같은 쿼리를 실행하지 않거나 어떤 쿼리가 실행될지 확실하지 않은 경우 한 가지 옵션은 열 여러 개 대신 열 하나에 한 행의 모든 데이터를 저장하는 것입니다. 이 방법을 사용하면 프로토콜 버퍼 바이너리 형식이나 JSON 파일과 같이 나중에 개별 값을 추출하기가 어려운 형식을 사용합니다.

row key는 필요한 데이터를 검색할 수 있도록 신중하게 설계되었지만 각 행에는 일반적으로 단일 protobuf의 행에 대한 모든 데이터가 포함된 열이 한 개만 있습니다.

데이터를 여러 열에 분산하는 대신 열 하나에 protobuf 메시지로 저장에는 장단점이 있습니다. 이점은 다음과 같습니다.

• 데이터가 공간을 적게 차지하므로 데이터 저장 비용이 줄어듭니다.
• column family 및 column qualifier를 커밋하지 않으므로 유연성을 일정 수준으로 유지할 수 있습니다.
• 읽기 애플리케이션에서는 테이블 스키마가 무엇인지를 '확인'할 필요가 없습니다.

일부 단점은 다음과 같습니다.

• protobuf 메시지를 Bigtable에서 읽은 후에 역직렬화해야 합니다.
• 필터를 사용하여 protobuf 메시지의 데이터를 쿼리하는 옵션을 사용할 수 없습니다.
• Bigtable에서 protobuf 메시지를 읽은 후 이 메시지 내 필드에서 제휴 쿼리를 실행하는 데 BigQuery를 사용할 수 없습니다.

다음 단계

• 시계열 데이터의 스키마 설계
• 스키마 계획과 관련된 단계 검토
• Bigtable에 보낼 수 있는 쓰기 요청 유형 알아보기
• 집계 셀을 사용하여 카운터 구현하기
• 관련 할당량 및 한도 살펴보기