스키마 설계

Bigtable 테이블에 적합한 스키마는 사용 사례, 데이터 액세스 패턴, 저장할 데이터를 포함하여 다양한 요인에 따라 크게 달라집니다. 이 페이지에서는 Bigtable 스키마 설계 프로세스를 간략하게 설명합니다.

이 페이지를 읽기 전에 스키마 설계 개념과 권장사항을 이해하고 있어야 합니다. 해당되는 경우 시계열 데이터의 스키마 설계도 참조하세요.

시작하기 전에

스키마를 테스트하는 데 사용할 수 있는 Bigtable 인스턴스를 만들거나 식별합니다.

정보 수집

  1. Bigtable에 저장하려는 데이터를 식별합니다. 다음과 같은 질문을 제출해 주세요.
    • 데이터는 어떤 형식을 사용하나요? 가능한 형식은 원시 바이트, 문자열, protobuf, json입니다.
    • 데이터의 항목은 어떻게 구성되나요? 예를 들어 페이지 조회수, 주가, 광고 게재위치, 기기 측정치, 다른 유형의 항목을 저장하나요? 항목은 어떻게 구성되어 있나요?
    • 데이터는 시간을 기반으로 하나요?
  2. 필요한 데이터를 가져오는 데 사용할 쿼리를 식별하고 순위를 결정합니다. 저장할 항목을 고려해 데이터를 사용할 때 데이터 정렬 및 그룹화 방법을 생각해 보세요. 스키마 설계가 모든 쿼리를 충족하는 것은 아니지만 가장 중요하거나 가장 자주 사용되는 쿼리를 충족하는 것이 가장 바람직합니다. 쿼리의 예시는 다음과 같습니다.
    • 한 달 동안의 IoT 객체 온도 판독값
    • IP 주소의 일일 광고 조회수
    • 휴대기기의 가장 최근 위치
    • 사용자당 일일 애플리케이션 이벤트 수

설계

초기 스키마 설계를 결정합니다. 즉, row key가 따라야 하는 패턴, 테이블에서 사용할 column family, 그리고 해당 column family 내에 있는 열의 column qualifier를 계획합니다. 일반 스키마 설계 가이드라인을 따릅니다. 데이터가 시간을 기반으로 하는 경우 시계열 데이터 가이드라인도 따라야 합니다.

테스트

  1. 스키마에 대해 작성한 column family와 column qualifier를 사용하여 테이블을 만듭니다.
  2. 임시 계획에서 식별한 row key를 사용하여 최소 30GB의 테스트 데이터가 있는 테이블을 로드합니다. 노드당 스토리지 사용량 한도 미만으로 유지합니다.
  3. 몇 분 동안 과도한 부하가 발생하는 테스트를 실행합니다. 이 단계를 통해 Bigtable은 관측된 액세스 패턴에 따라 노드 간에 데이터를 균등화할 수 있습니다.
  4. 일반적으로 테이블에 보내는 읽기 및 쓰기에 대해 1시간 시뮬레이션을 실행합니다.

  5. Key Visualizer 및 Cloud Monitoring을 사용하여 시뮬레이션 결과를 검토합니다.

    • Bigtable용 Key Visualizer 도구는 클러스터의 각 테이블에 대한 사용 패턴을 표시하는 일일 검사를 제공합니다. Key Visualizer를 사용하면 특정 행의 핫스팟과 같은 스키마 설계 및 사용 패턴으로 인해 원치 않는 결과가 발생하는지 확인할 수 있습니다.

    • Monitoring을 통해 클러스터에서 사용량 상위 노드의 CPU 사용률과 같은 측정항목을 확인하여 스키마 설계로 인해 문제가 발생하는지 확인할 수 있습니다.

상세검색

  1. Key Visualizer로 학습한 내용을 기반으로 필요에 따라 스키마 설계를 수정합니다. 예를 들면 다음과 같습니다.
    • 부하 집중 증거가 보이면 다른 row key를 사용합니다.
    • 지연 시간이 보인다면 행이 행당 100MB 한도를 초과하는지 확인합니다.
    • 필요한 데이터를 가져오기 위해 필터를 사용해야 하는 경우, row key별로 단일 행 또는 범위를 읽는 더 간단하고 빠른 읽기 방식으로 데이터를 정규화합니다.
  2. 스키마를 수정한 후 결과를 다시 테스트하고 검토합니다.
  3. Key Visualizer의 검사에서 스키마 설계가 최적이라고 판단할 때까지 스키마 설계 및 테스트를 계속 수정합니다.

다음 단계