안녕하세요~ 할부로애틋하게 BTC_손지수, 박은혜 입니다!
저번 주 포스팅을 통해 정형 데이터를 위한 스토리지에 대해 알아보았었습니다.
다양한 스토리지 옵션 중 Big Query에 대해 알아보았었는데요~!
오늘은 지연 시간이 중요한 경우에 사용할 수 있는 Bigtable에 대해 알아보고자 합니다.
그럼 이번 한 주도 GCP에 대해 더 가까워져 봅시다~!
Cloud Bigtable은 수십억 개의 행과 수천 개의 열까지 확장하여 수 테라바이트,
심지어 수 페타바이트의 데이터까지 저장할 수 있으며 데이터 밀도가 낮은 테이블입니다.
각 행의 단일 값에 대한 색인이 생성되는데, 이러한 값을 row key라고 부릅니다.
Bigtable은 매우 짧은 지연 시간으로 매우 많은 양의 단일 키 입력 데이터를 저장하는 데 적합합니다.
Cloud Bigtable은 낮은 지연 시간으로 높은 읽기 및 쓰기 처리량을 지원하며,
맵리듀스 작업에 이상적인 데이터 소스입니다.
따라서 저번 포스팅에서 말씀드린 거처럼 Bigtable의 경우 실시간 데이터와 같이 데이터의 양이 많고
지연 시간이 중요한 경우 이러한 Bigtable의 사용을 추천합니다.
그렇다면 이 외에 Bigtable의 다른 특징들은 무엇이 있는지 알아보고자 합니다!
첫 번째, 뛰어난 확장성입니다.
Bigtable은 클러스터에 있는 머신 수에 따라 확장됩니다.
따라서 클러스터를 계속 확장하여 더 많은 읽기 및 쓰기를 처리할 수 있습니다.
두 번째, 간단한 관리입니다.
Bigtable은 업그레이드 및 재시작을 투명하게 처리하고, 높은 데이터 내구성을 자동으로 유지합니다.
데이터를 복제할 때 두 번째 클러스터를 인스턴스에 추가하기만 하면 복제가 자동으로 시작됩니다.
더 이상 복제본 또는 리전을 관리할 필요가 없으며 테이블 스키마만 설계하면
Bigtable에서 나머지를 자동으로 처리합니다.
세 번째, 다운타임 없이 클러스터 크기 조절이 가능합니다.
Bigtable은 몇 시간 동안 클러스터 크기를 늘려서 대규모 로드를 처리한 후 클러스터 크기를 다시 줄일 수 있으며,
다운타임 없이 이 모든 작업을 수행할 수 있습니다.
(클러스터 크기를 변경하면 일반적으로 Bigtable에서 클러스터에 있는 모든 노드의 성능을 균등화하는 데 몇 분 정도 걸립니다.)
다음으로는 Bigtable의 장점은 무엇이 있는지 알아보고자 합니다.
Bigtable은 키/값 데이터에 매우 높은 처리량과 확장성이 필요한 애플리케이션에 적합합니다.
(여기서 각 값은 일반적으로 10MB 이하입니다.)
또한 Bigtable은 일괄 맵리듀스 작업, 스트림 처리/분석, 머신러닝 애플리케이션을 위한 스토리지 엔진으로도 탁월합니다.
Bigtable를 사용하면 다음과 같은 유형의 모든 데이터를 저장 및 쿼리 할 수 있습니다.
시계열 데이터 - 여러 서버의 시간별 CPU 및 메모리 사용량
마케팅 데이터 - 구매 내역 및 고객 선호도
재무 데이터 - 거래 내역, 주식 가격, 통화 환율
사물 인터넷 데이터 - 에너지 측정기 및 가전제품의 사용량 보고서
그래프 데이터 - 사용자가 서로 연결되는 방법에 대한 정보
구체적인 Bigtable의 형태에 대해 더 알아보고자 합니다!
Bigtable은 각각 정렬된 키/값 매핑으로 구성되어 있고 대규모로 확장 가능한 테이블에 데이터를 저장합니다.
이 테이블은 일반적으로 단일 항목을 기술하는 행과 각 행의 개별 값을 포함하는 열로 구성됩니다.
각 행은 단일 row key로 색인이 생성되고, 서로 연관된 열은 일반적으로 column family로 그룹화됩니다.
각 열은 column family와 column family 내 고유 이름인 column qualifier의 조합으로 식별됩니다.
각 행/열 교집합에는 여러 셀이 포함될 수 있습니다.
각 셀에는 행과 열의 타임스탬프가 적용된 고유한 버전의 데이터가 포함됩니다.
하나의 열에 여러 셀을 저장하면 해당 행, 열에 저장된 데이터가 시간에 따라
어떻게 변화했는지에 대한 레코드가 제공됩니다.
Bigtable 테이블은 희소합니다. 특정 행에 열이 사용되지 않으면 공간을 차지하지 않습니다.
(행에서 열이 사용되지 않을 수 있습니다. 주어진 행과 열의 각 셀에는 고유한 타임스탬프(t)가 있습니다.)
Bigtable의 전체적인 아키텍처는 다음과 같습니다.
데이터 흐름에 대해 살펴보자면,
모든 클라이언트 요청은 프런트 엔드 서버를 통과한 다음 Bigtable 노드로 전송됩니다.
이러한 노드를 '태블릿 서버'라고도 합니다.
이러한 노드는 클러스터의 컨테이너인 Bigtable 인스턴스에 속하는 Bigtable 클러스터로 구성됩니다.
이 클러스터의 각 노드는 클러스터에 대한 요청 중 일부를 처리합니다.
클러스터에 노드를 추가하면 클러스터가 처리할 수 있는 동시 요청 수를 늘리고,
전체 클러스터의 최대 처리량을 늘릴 수 있습니다.
두 번째 클러스터를 추가하여 복제를 활성화한 경우에는 다른 유형의 트래픽을 서로 다른 클러스터에 전송하고,
한 클러스터를 사용할 수 없을 때 다른 클러스터로 장애 조치를 수행할 수도 있습니다.
Bigtable 테이블은 태블릿이라고 하는 연속된 행의 블록으로 분할되어 쿼리 워크로드를 분산시킵니다.
태블릿은 Google 파일 시스템인 Colossus에 SSTable 형식으로 저장됩니다.
SSTable은 영구적이고 불변하며 정렬된 키-값 매핑을 제공하며, 키와 값은 모두 임의 바이트 문자열입니다.
각 태블릿은 특정 Bigtable 노드와 연결됩니다. SSTable 파일 외에도,
모든 쓰기 작업은 Bigtable에서 인식되는 즉시 Colossus의 공유 로그에 저장되어 내구성이 향상됩니다.
중요한 사실은 데이터가 Bigtable 노드 자체에 저장되지 않는다는 것입니다.
각 노드는 Colossus에 저장되는 태블릿 집합에 대한 포인터를 갖습니다. 결과는 다음과 같습니다!
실제 데이터가 복사되는 것이 아니기 때문에 한 노드에서 다른 노드로의 태블릿 재균등화가 매우 빠르게 수행됩니다. Bigtable은 단순히 각 노드에 대한 포인터만 업데이트합니다.
교체 노드에 메타데이터만 마이그레이션 하면 되기 때문에 Bigtable 노드 오류도 매우 빠르게 복구할 수 있습니다.
Bigtable 노드가 실패해도 데이터는 손실되지 않습니다.
지금까지 Bigtable에 대해 알아보았습니다!
정형 데이터를 위한 스토리지를 정할 때,
저희의 포스팅을 토대로 중요한 기준에 따라 Bigquery 혹은 Bigtable을 잘 택하시면 될 거 같습니다!
그럼 오늘 하루도 수고 많으셨고,
저희는 다음 주에 더욱 유익한 포스팅으로 찾아뵙겠습니다!
감사합니다~~
'CSP (Cloud Service Provider) > GCP' 카테고리의 다른 글
| [GCP] Cloud Dataflow (0) | 2022.06.16 |
|---|---|
| [GKE] Service Mesh Architecture과 Istio (0) | 2022.06.12 |
| Google Composer (0) | 2022.06.10 |
| [GCP] QWIKLABS (0) | 2022.06.09 |
| [Google Cloud Platform] GCP 스토리지, 컨테이너 - STRUCTURED DATA(1) (0) | 2022.06.07 |
댓글