시계열 데이터의 스키마 설계
이 페이지에서는 Bigtable에 시계열 데이터를 저장하기 위한 스키마 설계 패턴을 설명합니다. 이 페이지는 스키마 설계를 기반으로 하며 페이지에 설명된 개념과 권장사항에 익숙하다고 가정합니다.
시계열은 측정과 녹음된 시간으로 구성되는 데이터 모음입니다. 시계열의 예시는 다음과 같습니다.
- 컴퓨터 메모리 사용량 도표
- 뉴스 보고서의 시간별 온도
- 일정 기간의 주식 시장 가격
스키마를 올바르게 설계하면 성능과 확장성이 향상되지만, 잘못 설계할 경우 시스템 성능이 저하될 수 있습니다. 하지만 모든 경우에 최상의 결과를 제공할 수 있는 만능 스키마 설계란 없습니다.
이 페이지에서 설명하는 패턴은 시작점을 제공합니다. 고유한 데이터 세트와 사용할 쿼리는 시계열 데이터의 스키마를 설계할 때 가장 중요한 고려사항입니다.
Bigtable에 시계열 데이터를 저장하기 위한 기본 설계 패턴은 다음과 같습니다.
예시 데이터
패턴의 차이를 설명하기 위해 이 페이지의 예시에서는 날씨 풍선이 1분마다 한 번 측정한 값을 기록하는 앱의 데이터를 저장한다고 가정합니다. 동시에 하나 이상의 셀을 작성하는 단일 요청을 의미하기 위해 이벤트를 사용합니다. 위치 ID는 Google Cloud 리전에 해당합니다.
측정값 | 예시 |
---|---|
|
|
압력(파스칼) | 94587 |
온도(섭씨) | 9.5 |
습도(백분율) | 65 |
고도(미터) | 601 |
관련 데이터 | 예시 |
풍선 ID | 3698 |
위치 | asia-southeast1 |
타임스탬프1 | t2021-03-05-1204 |
시간 버킷
시간 버킷 패턴에서 테이블의 각 행은 시간, 일 또는 월과 같은 시간의 '버킷'을 나타냅니다. row key에는 week49
와 같이 행에 기록된 기간의 타임스탬프가 아닌 식별자와 다른 식별 데이터가 포함됩니다.
분, 시간, 일과 같이 사용하는 버킷의 크기는 사용할 쿼리와 Bigtable 데이터 크기 한도에 따라 다릅니다. 예를 들어 한 시간 분량의 데이터가 포함된 행이 100MB 행당 권장되는 최대 크기보다 크면 30분 또는 1분을 나타내는 행이 더 적합할 수 있습니다.
시간 버킷 패턴의 이점은 다음과 같습니다.
성능이 더 좋습니다. 예를 들어 100개의 측정값을 저장하는 경우 Bigtable은 이러한 측정값이 100개의 행에 있는 것보다 한 행에 있으면 더 빠르게 작성하고 읽습니다.
이러한 방식으로 저장된 데이터는 길고 좁은 테이블의 데이터보다 더 효율적으로 압축됩니다.
단점은 다음과 같습니다.
- 시간 버킷 스키마 설계 패턴은 단일 타임스탬프 패턴보다 더 복잡하며 개발에 더 많은 시간과 노력이 필요할 수 있습니다.
새 일정에 새 열 추가
이 시간 버킷 패턴에서는 셀 값이 아닌 column qualifier의 데이터를 저장하는 각 이벤트에 대해 행에 새 열을 작성합니다. 즉, 각 셀마다 column family, column qualifier, 타임스탬프를 전송하되 값은 전송하지 않습니다.
샘플 날씨 풍선 데이터에 이 패턴을 사용하면 각 행에 일주일 동안의 단일 날씨 풍선에 대한 pressure
와 같은 단일 측정항목의 모든 측정값이 포함됩니다. 각 row key에는 위치, 풍선 ID, 행에서 기록하는 측정항목, 주 번호가 포함됩니다. 풍선이 측정항목의 데이터를 보고할 때마다 행에 새 열을 추가합니다. column qualifier에는 셀 타임스탬프로 식별된 시간(분)의 측정값인 압력(파스칼 단위)이 포함됩니다.
이 예시에서 3분이 지나면 행은 다음과 같이 표시됩니다.
행 키 | 94558 | 94122 | 95992 |
---|---|---|---|
us-west2#3698#pressure#week1 | "" (t2021-03-05-1200) | "" (t2021-03-05-1201) | "" (t2021-03-05-1202) |
이 패턴의 사용 사례에는 다음이 포함됩니다.
시계열 데이터의 변경을 측정할 필요가 없습니다.
column qualifier를 데이터로 사용하여 저장 공간을 절약하려고 합니다.
새 일정에 사용할 새 셀 추가
이 시간 패턴에서는 새 이벤트를 기록할 때 기존 열에 새 셀을 추가합니다. 이 패턴을 사용하면 특정 행 및 열에 여러 타임스탬프 셀을 저장할 수 있는 Bigtable의 기능을 활용할 수 있습니다. 이 패턴을 사용할 때 가비지 컬렉션 규칙을 지정하는 것이 중요합니다.
각 지역의 날씨 풍선 데이터를 예로 들어 각 행에는 일주일 동안의 단일 날씨 풍선에 대한 모든 측정값이 포함되어 있습니다. row key 프리픽스는 주의 식별자이므로 단일 쿼리를 사용하여 여러 풍선에 대한 일주일 분량의 데이터를 읽을 수 있습니다. 다른 row key 세그먼트는 풍선이 작동하는 위치와 풍선의 ID 번호입니다. 이 테이블에는 column family가 한 개(measurements
) 있고 column family에는 각 측정 유형에 대한 한 열(pressure
, temperature
, humidity
, altitude
)이 있습니다.
풍선이 측정값을 전송할 때마다 애플리케이션에서 풍선에 대한 현재 주의 데이터가 포함된 행에 새 값을 작성하며 각 열에 추가 타임스탬프가 추가된 셀을 작성합니다. 주말에 각 행의 각 열에는 주의 1분당 측정값 1개 또는 셀 10,080개(가비지 컬렉션 정책에서 허용하는 경우)가 있습니다.
각 행의 각 열에는 주의 1분당 측정 값이 저장됩니다. 이 경우 3분이 지나면 행의 처음 두 열은 다음과 같이 표시됩니다.
행 키 | 압력 | temp |
---|---|---|
asia-south2#3698#week1 | 94558(t2021-03-05-1200) | 9.5(t2021-03-05-1200) |
94122(t2021-03-05-1201) | 9.4(t2021-03-05-1201) | |
95992(t2021-03-05-1202) | 9.2(t2021-03-05-1202) |
이 패턴의 사용 사례에는 다음이 포함됩니다.
- 시간에 따른 측정값의 변화를 측정하려고 합니다.
단일 타임스탬프 행
이 패턴에서는 기존 행의 열에 셀을 추가하는 대신 각 새 이벤트 또는 측정에 대한 행을 만듭니다. row key 서픽스는 타임스탬프 값입니다. 이 패턴을 따르는 테이블은 길고 좁은 경향이 있으며 행의 각 열은 하나의 셀만 포함합니다.
직렬화된 단일 타임스탬프
이 패턴에서는 행의 모든 데이터를 프로토콜 버퍼(protobuf)와 같은 직렬화된 형식으로 단일 열에 저장합니다. 이 방식은 스키마 설계에 자세히 설명되어 있습니다.
예를 들어 이 패턴을 사용하여 날씨 풍선 데이터를 저장하는 경우 4분 후에 테이블이 다음과 같이 표시될 수 있습니다.
행 키 | measurements_blob |
---|---|
us-west2#3698#2021-03-05-1200 | protobuf_1 |
us-west2#3698#2021-03-05-1201 | protobuf_2 |
us-west2#3698#2021-03-05-1202 | protobuf_3 |
us-west2#3698#2021-03-05-1203 | protobuf_4 |
이 패턴의 이점은 다음과 같습니다.
스토리지 효율성
속도
단점은 다음과 같습니다.
데이터를 읽을 때 특정 열만 검색할 수 없습니다.
데이터를 읽은 후 역직렬화를 해야 합니다.
이 패턴의 사용 사례에는 다음이 포함됩니다.
어떻게 데이터를 쿼리해야 할지 잘 모르겠으며 쿼리가 변동될 수 있습니다.
Bigtable에서 데이터를 검색하기 전에 데이터를 필터링할 수 있는 것보다 비용을 줄이는 것이 더 중요합니다.
이벤트마다 측정값이 너무 많아서 데이터를 여러 열에 저장하는 경우 행별 한도인 100MB를 초과할 수 있습니다.
비직렬화된 단일 타임스탬프
이 패턴에서는 측정이 하나만 기록되더라도 각 이벤트를 자체 행에 저장합니다. 열의 데이터는 직렬화되지 않습니다.
이 패턴의 이점은 다음과 같습니다.
일반적으로 시간 버킷 패턴보다 구현하기가 쉽습니다.
스키마를 사용하기 전에 스키마 수정에 소요되는 시간을 줄일 수 있습니다.
이 패턴의 단점은 종종 이점보다 영향이 큽니다.
이 패턴에서는 Bigtable의 성능이 저하됩니다.
이 방법으로 저장된 데이터는 더 넓은 열의 데이터만큼 효율적으로 압축되지 않습니다.
타임스탬프가 row key 끝에 있더라도 핫스팟이 발생할 수 있습니다.
이 패턴의 사용 사례에는 다음이 포함됩니다.
직렬화된 구조에 데이터를 저장하지 않을 이유가 있으며 모든 열에서 항상 지정된 타임스탬프 범위만 검색하려고 합니다.
이벤트 수를 무제한으로 저장하고 싶습니다
날씨 풍선 예시 데이터를 사용하는 경우 column family와 column qualifier는 시간 버킷과 새 셀을 사용하는 예시와 동일합니다. 그러나 이 패턴에서는 각 날씨 풍선에 보고된 모든 측정 집합이 새 행에 기록됩니다. 다음 패턴은 이 패턴을 사용하여 작성된 5개의 행을 보여줍니다.
행 키 | 압력 | 온도 | 습도 | 고도 |
---|---|---|---|---|
us-west2#3698#2021-03-05-1200 | 94558 | 9.6 | 61 | 612 |
us-west2#3698#2021-03-05-1201 | 94122 | 9.7 | 62 | 611 |
us-west2#3698#2021-03-05-1202 | 95992 | 9.5 | 58 | 602 |
us-west2#3698#2021-03-05-1203 | 96025 | 9.5 | 66 | 598 |
us-west2#3698#2021-03-05-1204 | 96021 | 9.6 | 63 | 624 |
추가 전략
동일한 데이터 세트에 여러 개의 쿼리를 전송해야 하는 경우 각 테이블에 쿼리 중 하나를 위해 설계된 row key를 사용하여 데이터를 여러 테이블에 저장하는 것이 좋습니다.
경우에 따라 패턴을 결합할 수도 있습니다. 예를 들어 행의 크기가 너무 커지지 않는 한 시간 버킷을 나타내는 행에 직렬화된 데이터를 저장할 수 있습니다.
다음 단계
- 스키마 계획과 관련된 단계 검토
- 스키마 설계 권장사항 이해하기
- Bigtable에서 기대할 수 있는 성능 알아보기
- Key Visualizer의 진단 기능 탐색하기