[GCP Associate Cloud Engineer] 데이터베이스

데이터베이스의 중요한 개념을 이해해보자.

만약 런던에 데이터 센터를 배포하고 그 안에 데이터베이스를 두었다고 가정하자. 그리고 이 데이터베이스에 연결하는 애플리케이션이 있을 경우 발생할 수 있는 몇 가지 주요 문제를 살펴보겠다.

 

데이터 센터가 다운되면 데이터베이스도 사용할 수 없다

데이터 센터가 장애를 일으키거나 서버의 저장 장치가 고장 나면 데이터베이스에 접근할 수 없게 된다. 이 경우 애플리케이션도 정상적으로 동작하지 못하게 된다.

이를 해결하기 위해 데이터베이스의 정기적인 스냅샷을 생성하여 다른 데이터 센터에 저장하는 방안을 고려할 수 있다. 예를 들어, 동일한 런던 지역의 두 번째 데이터 센터에서 한 시간마다 데이터베이스의 스냅샷을 자동으로 저장하도록 한다.

하지만 데이터 센터가 다운되면 데이터베이스가 중단되는 문제는 여전히 해결되지 않는다.

스냅샷이 있기 때문에 완전히 데이터가 손실되는 것은 아니지만, 스냅샷이 생성된 이후부터 장애가 발생하기 전까지의 데이터는 잃을 수 있다. 예를 들어, 4시 정각에 스냅샷을 저장했는데, 4시 50분에 데이터 센터가 다운되면 그 사이의 데이터는 손실될 수 있다.

 

데이터베이스가 충돌하면 데이터가 손실될 수 있다

데이터베이스가 충돌하면 단순히 데이터베이스가 접근 불가능해지는 것뿐만 아니라 저장된 데이터 자체를 잃을 수도 있다.

이 문제를 개선하기 위해 트랜잭션 로그를 도입할 수 있다. 트랜잭션 로그란 데이터베이스에서 수행되는 모든 변경 사항을 기록한 로그 파일이다.

스냅샷과 함께 트랜잭션 로그를 사용하면 장애가 발생하더라도 스냅샷에서 복구한 후 트랜잭션 로그를 적용하여 최근 변경 사항까지 복구할 수 있다.

즉, 데이터베이스가 충돌해도 트랜잭션 로그를 재적용하면 손실 없이 복구할 수 있다.

 

스냅샷을 생성하는 동안 데이터베이스의 속도가 느려진다

스냅샷을 생성하는 과정에서 디스크 I/O가 증가하고, 이에 따라 데이터베이스의 성능이 저하될 수 있다.

이를 위한 해결책으로 스탠바이 데이터베이스를 추가하고, 동기 복제를 설정할 수 있다.

이를 위해 두 개의 데이터 센터를 운영하며, 각각 하나의 데이터베이스를 배치한다.

마스터 데이터베이스는 애플리케이션이 연결하여 데이터를 읽고 쓰는 주 데이터베이스로 사용하고, 스탠바이 데이터베이스는 마스터 데이터베이스와 동기화된 상태로 유지되는 백업 데이터베이스로 사용된다.

여기서 동기 복제를 적용하면 마스터 데이터베이스에서 변경이 발생할 때마다 스탠바이 데이터베이스에도 즉시 동일한 변경이 적용된다.

또한 스냅샷을 스탠바이 데이터베이스에서 생성하면 마스터 데이터베이스의 성능 저하 문제도 해결할 수 있다.

데이터베이스의 가용성과 내구성

가용성

가용성은 내가 필요할 때 데이터를 충분히, 언제든지 접근할 수 있는지를 의미한다.
즉, 애플리케이션이 예상된 기능을 제공하는 시간의 비율로 측정된다.

가용성은 퍼센트로 나타내며, 높은 가용성(High Availability, HA)을 유지하는 것이 중요하다.
가용성을 평가하는 대표적인 기준으로 9의 개수가 사용된다.

가용성(%)	허용 가능한 월간 다운타임
99.95%	약 22분
99.99%	약 4.5분
99.999% (Five Nines)	약 26초

 

99.95% 가용성: 한 달에 최대 22분 동안 서비스가 중단될 수 있다.

99.99% 가용성: 한 달 동안 서비스 중단 시간이 4분 30초 이내여야 하는 것으로 일반적으로 모든 온라인 애플리케이션이 목표로 하는 수준이다.

99.999% 가용성: 한 달 동안 26초 이하의 다운타임만 허용되는 것으로 현실적으로 달성하기 매우 어려운 수준이다.

 

여기서  주의할 점은 서비스 배포 시간도 포함되기 때문에 한 달 동안 5번의 배포를 진행하더라도 총 다운타임이 해당 기준을 넘으면 안된다는 것이다.

 

가용성을 증가시키는 방법

가용성을 높이기 위해서는 여러 개의 스탠바이 데이터베이스를 운영하는 것이 중요하다.
즉, 기본 데이터베이스가 다운되었을 때 스탠바이 데이터베이스가 사용자 요청을 처리할 수 있도록 준비하는 것이다. 이를 통해 데이터베이스 장애로 인한 서비스 중단 시간을 최소화할 수 있다.

또한, 단순히 한 개의 스탠바이를 운영하는 것이 아니라, 여러 개의 스탠바이를 두는 것이 더욱 높은 가용성을 보장할 수 있는 방법이다.
이런 방식으로 데이터베이스를 분산시키는 것을 데이터베이스 분산이라고 한다.

특히 다중 존 및 다중 지역에 데이터베이스를 분산 배치하면, 특정 데이터센터나 지역에서 장애가 발생하더라도 다른 존 혹은 지역에서 데이터를 제공할 수 있기 때문에, 더욱 높은 가용성을 확보할 수 있다.

 

내구성

내구성은 10년, 100년, 1000년 후에도 내 데이터가 유지될 것인가를 의미한다.
즉, 저장된 데이터가 손실되지 않고 유지되는 정도를 나타낸다.

내구성은 보통 11 Nines, 즉 99.999999999%로 측정된다.
이는 다음과 같은 의미를 갖는다.

 

1백만 개의 파일을 1천만 년 동안 저장할 경우, 단 1개의 파일만 손실될 가능성이 있음.

 

즉, 데이터가 거의 절대적으로 안전하게 유지된다고 볼 수 있다.

 

내구성이 가용성보다 더 주요하게 여겨지는 이유는 가용성이 잠시 떨어지는 것은 용인될 수 있지만, 데이터 손실은 절대 용납할 수 없다. 왜냐하면 애플리케이션이 몇 분 동안 중단되는 것은 감수할 수 있지만, 데이터가 한 번 손실되면 영원히 복구할 수 없기 때문이다.

예를 들어, 금융 거래 데이터 손실 이 발생할 경우 고객의 돈이 사라질 수 있고, 의료 데이터 손실이 발생하면 환자의 중요한 의료 기록이 삭제될 수 있다. 이처럼 데이터는 절대적으로 보존되어야 하며, 이를 보장하기 위해 높은 내구성이 필수적이다.

 

내구성을 증가시키는 방법

내구성을 높이는 방법은 여러 개의 데이터 사본을 유지하는 것이다.

스탠바이 데이터베이스 유지 - 장애 발생 시 즉시 전환할 수 있도록 대기 중인 데이터베이스

스냅샷(snapshot) 생성 - 특정 시점의 데이터 상태를 저장하여 복구 시 활용

트랜잭션 로그(transaction log) 유지 - 데이터 변경 이력을 저장하여 장애 발생 시 복구 가능

복제(replication) 설정 - 여러 개의 데이터베이스에 동일한 데이터를 저장하여 일관성 유지

 

이러한 데이터 복제는 내구성을 높이는 데 필수적인 요소지만, 단순히 복제하는 것만으로는 문제가 해결되지 않는다.

데이터를 여러 개 복제하는 것은 장점이 많지만, 데이터의 일관성 문제가 발생할 수 있다.
즉, 여러 개의 데이터 사본이 존재할 경우, 어떤 데이터가 최신 상태인지, 모든 사본이 동일한 데이터를 유지하고 있는지를 확인하는 것이 중요하다.

이러한 일관성 문제를 해결하는 방법은 여러 가지가 있으며, 대표적으로 강한 일관성 보장, 최종적 일관성 유지 등의 기법을 사용할 수 있다.

RTO & RPO

RTO(복구 시간 목표, Recovery Time Objective)

장애가 발생했을 때 시스템을 복구하는 데 걸리는 최대 허용 시간으로 얼마나 빨리 서비스를 복구할 수 있는지를 의미한다.

예를 들어, RTO가 45분이라면 장애가 발생한 후 45분 이내에 시스템이 정상 복구되어야 한다.

 

RPO(복구 시점 목표, Recovery Point Objective)

장애 발생 시 허용할 수 있는 최대 데이터 손실 시간으로 얼마 동안의 데이터를 잃어도 괜찮은지를 의미한다.

예를 들어, RPO가 48시간이라면 마지막 백업 이후 48시간 동안의 데이터는 손실될 수 있다는 의미이다.

리드 레플리카

기존 데이터베이스 위에 새로운 애플리케이션을 추가한 경우 시간이 지나면서 데이터베이스 성능이 저하가 발생할 수 있다.

이를 위한 해결 방법으로는 다음과 같은 것이 있다.

 

수직 확장(Vertical Scaling)

CPU와 메모리를 추가하여 데이터베이스의 성능을 높이는 방법이다.

간단한 해결책이지만, CPU 코어 개수, 메모리 제한 등과 같은 물리적인 한계가 존재하며, 비용이 증가할 수 있다.

 

데이터베이스 클러스터(Database Clustering)

여러 개의 데이터베이스 인스턴스를 연결하여 부하를 분산하는 방법이다.

설정과 유지보수가 복잡하고 비용이 높다는 단점이 있다.

일반적으로 분산형 NoSQL 데이터베이스에서 클러스터링이 효과적이지만, 관계형 데이터베이스에서는 비용이 많이 든다.

 

리드 레플리카(Read Replica) 활용

읽기 전용 복제본을 생성하여 읽기 부하를 분산하는 방법이다.

새로운 분석 및 리포팅 애플리케이션을 리드 레플리카에 연결하여 메인 데이터베이스의 부하를 줄일 수 있다.

 

리드 레플리카의 장점은 읽기 전용 애플리케이션을 리드 레플리카에 연결하면 메인 데이터베이스의 부하가 줄어들어 성능이 향상된다.

일부 데이터베이스 시스템에서는 리드 레플리카를 마스터 데이터베이스로 승격할 수 있다. 즉, 메인 데이터베이스가 다운되면 리드 레플리카를 승격하여 장애를 복구하여 고가용성을 확보할 수 있다.

그리고 여러 지역에 리드 레플리카를 배포하면 사용자 가까운 곳에서 데이터를 읽을 수 있어 응답 속도가 향상된다.

스냅샷을 생성할 때 데이터베이스 성능이 일시적으로 저하될 수 있는데, 리드 레플리카를 활용하면 메인 데이터베이스의 성능을 유지하면서도 백업이 가능하다.

 

데이터 일관성

데이터베이스에서 여러 복제본을 운영할 때, 일관성을 유지하는 것이 중요하다.

 

강한 일관성(Strong Consistency)

동기적 복제를 사용하여 모든 복제본에 동시에 변경사항을 적용한다.

이는 변경 즉시 모든 복제본에 동일한 데이터가 반영 되어 만약 데이터베이스에 5개의 복제본이 있다면, 변경사항이 모든 복제본에 반영될 때까지 트랜잭션이 완료되지 않는다.

따라서 항상 일관된 데이터를 보장한다는 장점이 있지만 트랜잭션 속도가 느려질 수 있다는 단점도 가지고 있다.

그리고 복제본 수가 많을수록 지연 시간이 길어지기 때문에 성능 저하가 발생할 수 있다.

 

 

최종적 일관성(Eventual Consistency)

비동기적 복제를 사용하여 일정 시간 후에 모든 복제본이 동일한 상태가 되도록 보장한다.

변경사항이 일부 복제본에 먼저 반영되고, 시간이 지나면서 다른 복제본에도 전파되기 때문에 일시적으로 다른 복제본에서 다른 값을 반환할 수 있다.

높은 확장성을 제공하고, 성능 향상이 가능한 장점을 가지고 있지만, 일시적인 데이터 불일치 발생 가능하다는 단점도 가지고 있다.

 

쓰기 후 읽기 일관성(Read-After-Write Consistency)

삽입 작업은 즉시 모든 복제본에 반영되지만, 수정 작업은 최종적 일관성을 따른다.

삽입된 데이터는 즉시 모든 복제본에서 조회 가능하고, 수정된 데이터는 시간이 지나면서 복제본에 반영된다.

삽입된 데이터는 즉시 사용 가능하고, 업데이트 성능 향상 가능하다는 장점을 가지고 있고, 수정 시 일시적인 데이터 불일치 발생 가능한 단점도 가지고 있다.

데이터베이스의 유형

관계형 데이터베이스(Relational Database, RDB)

 

고정된 스키마를 사용하여 데이터를 저장하기 전에 테이블 구조를 정의해야 하며, 데이터의 형식을 엄격히 준수해야 한다.

ACID(Atomicity, Consistency, Isolation, Durability) 특성을 강하게 보장한다.

원자성(Atomicity): 모든 작업이 성공적으로 완료되거나, 실패하면 롤백됨

일관성(Consistency): 데이터베이스의 규칙을 항상 유지

격리성(Isolation): 여러 트랜잭션이 동시에 실행될 때 독립성 보장

내구성(Durability): 트랜잭션 완료 후에도 데이터가 영구적으로 저장됨

 

관계형 데이터베이스의 기본 구조

ID (PK)	학과명(department_name)	강사 ID(instructor_id)	기간(duration)	이름(name)
101	컴퓨터공학	2001	16주	알고리즘
102	수학	2002	12주	선형대수

 

ID(기본 키, Primary Key): 테이블 내에서 고유한 값을 가지며, 검색을 빠르게 수행할 수 있도록 한다.

 

추가적으로 외래 키를 사용하여 테이블 간 관계를 정의할 수 있다.

 

관계형 데이터베이스의 주요 사용 사례

 

OLTP (Online Transaction Processing, 온라인 트랜잭션 처리)

대량의 사용자가 짧고 빈번한 트랜잭션을 수행하는 애플리케이션을 처리하는 방식이다.

한 행의 모든 데이터를 한 번에 저장한다.

트랜잭션 단위는 작지만, 읽기, 쓰기, 업데이트, 삭제 작업이 많다.

Google Cloud에서는 OLTP를 위한 Cloud SQL과 Cloud Spanner를 제공한다.

 

 - Cloud SQL

Cloud SQL은 Google Cloud에서 제공하는 관리형 RDB 서비스로, PostgreSQL, MySQL, SQL Server를 지원한다.

기본적으로 관리형 서비스이기 때문에 인프라 관리 없이 데이터베이스 운영이 가능하고, 몇 TB 규모의 데이터 저장 가능하다. 리전 내에서만 사용 가능하지만 백업 및 자동 복구를 지원한다.

주로 전자상거래, 금융, CRM, ERP 시스템과 같은 소규모~중간 규모의 OLTP 애플리케이션에서 사용된다.

다만, 수직 확장 위주로 설계되어 있어 대규모 확장이 어렵기 때문에 글로벌 애플리케이션에는 적합하지 않다.

 

 - Cloud Spanner

Cloud Spanner는 Google이 제공하는 글로벌 확장 가능한 관계형 데이터베이스 서비스이다.

수평 확장을 지원하여 페타바이트급 데이터 저장이 가능하고, 99.999% SLA 보장하여 초고가용성을 가지고 있다.
글로벌 데이터베이스 구축 가능하고, 강력한 트랜잭션과 높은 확장성을 보장한다.
다만, Cloud SQL보다 비용이 높고, 기존의 MySQL, PostgreSQL, SQL Server와 완전히 동일한 방식으로 동작하지 않는다.

따라서 초대형 OLTP 애플리케이션이나 글로벌 서비스를 운영할 경우나, 수십억 건의 트랜잭션을 처리해야 한다면 Cloud Spanner가 좋은 선택지가 될 수 있다.

 

Cloud SQL vs. Cloud Spanner 

특징	Cloud SQL	Cloud Spanner
지원 DB	PostgreSQL, MySQL, SQL Server	Spanner 전용 SQL
데이터 크기	수 TB까지	수 PB까지 (무제한 확장)
확장성	수직 확장	수평 확장
가용성	지역 내 가용	글로벌(다중 Region 지원)
SLA(서비스 가용성)	99.95%	99.999%
트랜잭션 지원	강한 일관성(ACID)	강한 일관성(ACID)
사용 사례	중소규모 OLTP	대규모 OLTP, 글로벌 서비스

 

OLAP (Online Analytical Processing, 온라인 분석 처리)

대량의 데이터(수 테라바이트~페타바이트)를 분석하고 복잡한 쿼리를 실행하는 데이터 처리 방식이다.

같은 컬럼 데이터끼리 연속적으로 저장한다.

과거 데이터 기반의 의사 결정을 지원하고 주로 읽기 작업이 많다.

BI(Business Intelligence) 애플리케이션, 데이터 웨어하우스, 분석 시스템 등에서 사용된다.

Google Cloud의 OLAP 서비스로는 BigQuery가 있다.

 

 - BigQuery

BigQuery는 Google Cloud의 완전 관리형 OLAP 데이터 웨어하우스이다.
페타바이트급 데이터 저장이 가능하고, 완전 서버리스 서비스이기 때문에 인프라 관리 불필요하다.

열 기반 저장 방식을 사용하여 대량 데이터 분석에 최적화되어있다.
분산 병렬 처리로 하나의 쿼리를 여러 노드에서 동시에 실행하여 속도를 향상 시킨다.
SQL 지원을 통해 기존 SQL 문법을 기반으로 분석 쿼리 실행 가능하다.

 

OLAP과 OLTP의 차이점

비교 항목	OLTP	OLAP
목적	빠른 트랜잭션 처리 (INSERT, UPDATE, DELETE)	대량 데이터 분석 및 복잡한 쿼리 처리
데이터 크기	GB ~ TB 수준	TB ~ PB 수준
쿼리 유형	단순 조회, 짧은 트랜잭션	복잡한 집계, 다차원 분석
데이터 모델	정규화된 테이블(3NF 이상)	비정규화된 테이블 (스타 스키마, 스노우플레이크 스키마)
저장 방식	행 저장 방식	열 저장 방식
성능 최적화 방향	빠른 트랜잭션 응답 속도	대량 데이터에 대한 빠른 분석 쿼리 실행
사용 사례	은행 시스템, 전자상거래, ERP	BI, 데이터 웨어하우스, 마케팅 분석

 

관계형 데이터베이스의 장점과 단점

 

장점

 - 데이터 무결성과 일관성 보장
 - 강력한 트랜잭션 지원(ACID 준수)
 - 복잡한 쿼리와 관계를 효율적으로 처리 가능

 

단점

 - 확장성 한계로 NoSQL보다 수평 확장이 어려움
 - 스키마 변경이 어렵고 유연성이 부족
 - 대규모 데이터 처리 시 성능 저하 가능

 

문서형 데이터베이스(Document Database)

 

JSON, BSON 같은 반정형 데이터를 저장한다.

스키마가 유연하며, 관계형 데이터베이스보다 더 자유로운 데이터 모델링 가능하다.

사용 사례: NoSQL 기반의 웹 애플리케이션, 콘텐츠 관리 시스템

 

NoSQL 데이터베이스

전통적인 관계형 데이터베이스와 달리 유연한 스키마와 수평 확장성을 제공하는 데이터베이스 모델이다.

빠른 읽기/쓰기 성능으로 대량의 데이터 처리 가능하고, 강한 일관성을 일부 희생하고 성능과 확장성을 확보하였다.

 

Google Cloud의 NoSQL 데이터베이스 서비스

 

 - Cloud Firestore (구 Cloud Datastore)

Cloud Firestore는 Google이 제공하는 서버리스 NoSQL 문서형 데이터베이스이다.

기존 Cloud Datastore의 업그레이드 버전이며, 강한 일관성을 제공한다.

모바일 및 웹 애플리케이션 개발을 위해 최적화되어 있다.

서버리스 관리형 NoSQL 문서형 데이터베이스이고, 트랜잭션을 지원한다.

SQL과 유사한 쿼리 및 인덱싱 제공한다.

소규모~중규모 데이터베이스가 필요한 경우에 주로 사용하고, 모바일 및 웹 애플리케이션 개발 시 실시간 데이터 동기화가 필요한 경우와 Firebase 기반 애플리케이션과 연동이 필요한 경우 사용하면 유용하다.

 

 - Cloud Bigtable

Cloud Bigtable은 Google이 제공하는 페타바이트급 확장 가능한 와이드 컬럼 NoSQL 데이터베이스이다.

Google 내부에서 검색 색인, 광고 시스템, 애널리틱스, IoT 데이터 등을 처리하는 데 사용된다.

수직 확장 대신 수평 확장을 지원하고, 자동 샤딩 및 분산 저장이 된다.

다만, 서버리스가 아니기 때문에 인스턴스를 직접 생성해야 하고, 다중 행 트랜잭션이 지원 안된다.

 

Cloud Firestore vs. Cloud Bigtable

비교 항목	Cloud Firestore	Cloud Bigtable
데이터 모델	문서형(Document) 데이터베이스	와이드 컬럼(Wide-Column) 저장
확장성	수 TB까지 적합	수 PB까지 적합
트랜잭션 지원	다중 행 트랜잭션(ACID) 지원	단일 행 트랜잭션만 지원
쿼리 지원	SQL 유사한 쿼리 가능	SQL 지원 없음
사용 사례	모바일/웹 앱 데이터, 실시간 데이터 저장	IoT, 로그 데이터, 운영 데이터
서버리스 여부	서버리스 (자동 확장)	직접 인스턴스 생성 필요
Firebase 연동 가능	가능	불가능

 

키-값(Key-Value) 데이터베이스

Key-Value 쌍으로 데이터를 저장하는 간단한 구조이다.

빠른 조회 성능을 제공하며 캐싱 및 세션 관리에 적합하다.

사용 사례: Redis, DynamoDB

 

그래프 데이터베이스(Graph Database)

노드와 엣지로 구성된 데이터 모델이다.

데이터 간의 복잡한 관계를 빠르게 탐색 가능하다.

사용 사례: 소셜 네트워크, 추천 시스템

 

인메모리(In-Memory) 데이터베이스

데이터를 디스크가 아닌 메모리(RAM)에 저장하여 초고속 데이터 접근을 가능하게 하는 데이터베이스이다.

디스크보다 훨씬 빠른 속도를 제공하며, 캐싱, 세션 관리, 게임 리더보드, 실시간 데이터 분석 등에 사용된다.

주로 Key-Value Store 형태를 사용해 빠른 조회/쓰기 성능을 제공한다.
일반적으로 비관계형 구조로 유연한 데이터 모델 지원한다.
트랜잭션 로그를 사용하여 영속성 보장 가능하다.

 

Google Cloud의 인메모리 데이터베이스 서비스 - Memorystore

Memorystore는 Google Cloud에서 제공하는 완전 관리형 인메모리 데이터베이스 서비스이다.
Memorystore는 Redis와 Memcached 두 가지 옵션을 제공한다.

 

 - Redis

Redis 기반의 인메모리 데이터베이스로, 캐싱, 세션 저장, 순위 계산 등에 최적화된다.

데이터 영속성 지원 가능하고, 복제 및 자동 페일오버 기능을 제공하여 가용성을 확보하였다.

정렬된 집합과 같은 강력한 데이터 구조를 제공한다.

 

Redis 인스턴스 생성하기

 

 - Memcached

Memcached 기반의 인메모리 데이터베이스로, 고속 캐싱 및 분산 시스템에서의 데이터 저장에 최적화됐다.

단순 Key-Value 저장만 제공하며, Redis보다 기능이 제한적이지만 처리 속도가 매우 빠르다.

데이터 영속성이 없고 모든 데이터는 휘발성이다.

 

Memcached 인스턴스 만들기

 

 

Memorystore for Redis vs. Memorystore for Memcached

비교 항목	Memorystore for Redis	Memorystore for Memcached
데이터 모델	Key-Value + 복잡한 데이터 구조 지원	단순 Key-Value 저장
데이터 영속성(Persistence)	지원 (RDB, AOF 옵션)	지원 안 함
고가용성(HA) 지원	가능 (복제 및 페일오버)	없음
트랜잭션 지원	가능	없음
주요 사용 사례	세션 관리, 실시간 분석, 순위 관리	데이터베이스 조회 결과 캐싱

Cloud SQL 명령어

Cloud SQL을 다룰 때는 gcloud sql 명령어를 사용한다.

Cloud SQL을 사용하기 위해서는 먼저 인스턴스를 생성한 후, 그 인스턴스 내에 데이터베이스를 생성해야 한다.

# 인스턴스 생성
gcloud sql instances create [INSTANCE_NAME]

# 인스턴스 삭제
gcloud sql instances delete [INSTANCE_NAME]

# 인스턴스 정보 조회
gcloud sql instances describe [INSTANCE_NAME]

# 인스턴스 복제
gcloud sql instances clone [SOURCE_INSTANCE] [TARGET_INSTANCE]

#

 

데이터베이스 관리

# 데이터베이스 생성
gcloud sql databases create [DATABASE_NAME] --instance=[INSTANCE_NAME]

# 데이터베이스 삭제
gcloud sql databases delete [DATABASE_NAME] --instance=[INSTANCE_NAME]

# 데이터베이스 정보 조회
gcloud sql databases describe [DATABASE_NAME] --instance=[INSTANCE_NAME]

# 데이터베이스 목록 조회
gcloud sql databases list --instance=[INSTANCE_NAME]

 

 

Cloud SQL에 접속할 때는 gcloud sql connect 명령어를 사용한다.

gcloud sql connect [INSTANCE_NAME] --user=[USERNAME]

BigQuery 명령어

BigQuery를 사용할 때는 bq 명령어를 사용한다.
BigQuery에서는 주로 데이터를 조회하고, 데이터를 가져오거나 내보내는 작업을 수행한다.

# 데이터셋 조회
bq show [PROJECT_ID]:[DATASET_NAME]

출력 결과에는 해당 데이터셋의 필드 목록, 총 행(row) 개수, 데이터 크기 등의 정보가 포함된다.

 

BigQuery에서 쿼리 실행

BigQuery의 핵심 기능은 쿼리를 실행하여 데이터를 조회하는 것이다.

bq query --use_legacy_sql=false 'SELECT * FROM `bigquery-public-data.samples.Shakespeare` LIMIT 10;'

 

--use_legacy_sql=false 옵션을 사용하여 표준 SQL을 활성화해야 한다.

BigQuery는 대용량 데이터를 다루므로 쿼리를 실행하기 전에 예상 비용을 확인하는 것이 중요하다.

 

데이터 내보내기(Extract):

# 데이터 내보내기
bq extract --destination_format=CSV [PROJECT_ID]:[DATASET_NAME].[TABLE_NAME] gs://[BUCKET_NAME]/[FILENAME].csv

# 데이터 불러오기
bq load --source_format=CSV [PROJECT_ID]:[DATASET_NAME].[TABLE_NAME] gs://[BUCKET_NAME]/[FILENAME].csv

 

Cloud BigTable 명령어

Cloud BigTable을 사용할 때는 cbt 명령어를 사용한다.

 

Cloud BigTable에서는 프로젝트 설정을 gcloud config set project가 아니라 .cbtrc 설정 파일을 사용하여 지정해야 한다.

echo "project = [PROJECT_ID]" > ~/.cbtrc

이렇게 하면 BigTable CLI에서 자동으로 프로젝트 ID를 인식한다.

# 인스턴스 생성
cbt createinstance [INSTANCE_ID] [DISPLAY_NAME] [CLUSTER_ID] [ZONE] [STORAGE_TYPE]

# 클러스터 생성
cbt createcluster [CLUSTER_ID] [INSTANCE_ID] [ZONE] [STORAGE_TYPE]

# 테이블 생성
cbt createtable [TABLE_NAME]