SQL 및 타 클라우드(AWS·Azure)/DB 경력 엔지니어를 위한 4일 완성 과정
Google Cloud
Data & Database.
Google Cloud Data & Database Engineer · 1일차
GCP 기초와
데이터 레이크 · DB 선택.
오늘의
흐름
- 01Resource Hierarchy · IAM & gcloud CLI1–2교시 · 멀티 클라우드 매핑 & Lab 1 (gcloud · IAM 권한 바인딩)
- 02Cloud Storage 데이터 레이크 · 수명주기3–4교시 · 4대 스토리지 클래스 & Lab 2 (Lifecycle JSON 자동화)
- 03멀티 클라우드 DB 매핑 · Cloud SQL & AlloyDB5–6교시 · OLTP vs OLAP · Multi-Zone HA · Read Replica · PITR
- 04Database Selection Framework & HA 실습7–8교시 · 워크로드별 DB 의사결정 매트릭스 & Lab 3 (HA · Failover)
Resource Hierarchy · IAM & gcloud CLI
1–2교시 · AWS/Azure 경력자를 위한 GCP 리소스 계층 구조와 최소 권한 모델
- Organization · Folder · Project
- AWS · Azure 1:1 매핑
- Principal · Role · Policy
- Lab 1 · gcloud CLI & IAM
리소스 계층 구조와 멀티 클라우드 1:1 매핑
- Organization도메인(Workspace / Cloud Identity) 최상위 루트 · 전사 정책 통제
- Folder부서·본부·환경(Prod/Dev) 단위 그룹화 · 다단계 중첩 지원
- Project과금·API 활성화·IAM·VPC 격리 기본 단위 (모든 리소스의 소속점)
- ResourceCloud Storage, Cloud SQL, BigQuery 등 실제 서비스 인스턴스
| 계층 역할 | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| 최상위 조직 루트 | AWS Organizations (Root) | Tenant Root Group | Organization |
| 부서·환경 묶음 | Organizational Unit (OU) | Management Group | Folder |
| 과금·리소스 격리 단위 | AWS Account | Subscription + Resource Group | Project (Project ID 고유 식별) |
| 표준 CLI 도구 | aws cli | az cli | gcloud / gcloud storage / bq |
IAM 권한 체계: Principal + Role = Policy
상위 계층(Organization → Folder → Project)에서 부여한 권한은 하위 리소스로 자동 상속(Allow 합집합)돼요.
Google 계정(User), Google 그룹(Group), 서버·파이프라인용 서비스 계정(Service Account), Cloud Identity 도메인
Basic(Owner·Editor·Viewer, 실무 지양), Predefined(직무·서비스별 세분화 권장), Custom(최소 권한 직접 조합)
특정 Project·Bucket·Table에 Principal과 Role을 묶은 JSON 바인딩 (명시적 Deny 정책 외에는 하위에서 상위 Allow 해제 불가)
Lab 1 · gcloud CLI & IAM 권한 바인딩 실습
# 1. 프로젝트 ID 변수 등록 및 기본 리전 설정
export PROJECT_ID=$(gcloud config get-value project)
gcloud config set compute/region us-central1
# 2. 파이프라인용 서비스 계정(SA) 생성
gcloud iam service-accounts create pipeline-sa \
--display-name="Data Pipeline SA"
# 3. Predefined Role(Object Viewer) 바인딩
SA=pipeline-sa@${PROJECT_ID}.iam.gserviceaccount.com
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member="serviceAccount:$SA" \
--role="roles/storage.objectViewer"
- Cloud Shell 기본 환경gcloud·bq·cbt CLI가 사전 설치된 5GB 영구 홈 디렉터리 제공
- add-iam-policy-binding기존 프로젝트 정책에 주체(member)와 역할(role)을 안전하게 추가
- 실습 체크포인트IAM 콘솔과 CLI 양쪽에서 역할 부여 및 권한 회수(remove) 확인
Lab 1 · A Tour of Google Cloud Hands-on Labs (skills.google)gcloud add-iam-policy-binding 레퍼런스
Cloud Storage 데이터 레이크 · 수명주기
3–4교시 · 연간 99.999999999%(11 9s) 내구성의 단일 API 객체 스토리지와 비용 자동화
- Standard · Nearline · Coldline · Archive
- AWS S3 · Azure Blob 비교
- Object Lifecycle Management
- Lab 2 · gcloud storage & Lifecycle
스토리지 클래스 선택 기준과 3사 매핑
네 클래스 모두 첫 바이트 응답 지연(밀리초)과 단일 API가 동일하며, 최소 보관 기간과 조회(Retrieval) 단가만 달라요.
| 클래스 | 권장 접근 빈도 | 최소 보관 기간 | AWS S3 대응 | Azure Blob 대응 |
|---|---|---|---|---|
| Standard | 실시간 · 자주 접근 (핫 데이터, 분석 원본) | 없음 | S3 Standard | Hot Tier |
| Nearline | 월 1회 이하 (백업, 월간 리포트 원본) | 30일 | S3 Standard-IA | Cool Tier (30일) |
| Coldline | 분기 1회 이하 (재해 복구, 분기 감사 로그) | 90일 | S3 Glacier Instant Retrieval | Cold Tier (90일) |
| Archive | 연 1회 이하 (법적 장기 보관, 규정 준수) | 365일 | S3 Glacier Deep Archive | Archive Tier (오프라인) |
객체 수명주기(Lifecycle) 자동화와 보안 통제
- 수집 직후 (0–29일)Standard 클래스 · 실시간 파이프라인 및 Lakehouse 외부 테이블 조회
- 30일 경과 (Age: 30)SetStorageClass → Nearline 자동 전환으로 저장 단가 절감
- 90일 경과 (Age: 90)SetStorageClass → Coldline / Archive 장기 아카이빙 전환
- 365일 경과 (Age: 365)Delete 액션으로 만료 로그 영구 삭제 · 개인정보/보관 규정 준수
객체별 개별 ACL을 비활성화하고 오직 IAM 정책으로만 권한을 일원화해 감사 추적과 BigQuery Lakehouse 연동을 단순화해요.
접근 주기를 예측하기 어려우면 Autoclass로 자동 티어링하고, 실수 삭제 및 덮어쓰기 방지는 Object Versioning과 Soft Delete로 보호해요.
Object Lifecycle Management 공식 문서Uniform Bucket-Level Access 가이드
Lab 2 · gcloud storage & 수명주기 규칙 실습
# 1. Uniform Access 데이터 레이크 버킷 생성
gcloud storage buckets create gs://$PROJECT_ID-lake \
--location=us-central1 --uniform-bucket-level-access
# 2. 30일 경과 → Nearline 전환(lifecycle.json)
{"rule": [{
"action": {"type": "SetStorageClass",
"storageClass": "NEARLINE"},
"condition": {"age": 30}
}]}
# 3. 수명주기 정책 적용 및 조회
gcloud storage buckets update gs://$PROJECT_ID-lake \
--lifecycle-file=lifecycle.json
- gcloud storage 표준 CLIgsutil은 2027-03 제거 예정 레거시예요. 실무는 gcloud storage를 쓰고, 랩 지문의 gsutil도 그대로 동작해요
- JSON 조건(Condition) 조합age, createdBefore, matchesPrefix, isLive 등 복수 조건 지정 시 AND 조건으로 평가
- 비동기 반영정책 적용 후 실제 클래스 변경·삭제 실행까지는 최대 24시간 소요 가능
Lab 2 · Cloud Storage Qwik Start (skills.google)gcloud storage CLI 레퍼런스
멀티 클라우드 DB 매핑 · Cloud SQL & AlloyDB
5–6교시 · OLTP와 OLAP 워크로드 분리 및 관리형 관계형 데이터베이스 고가용성 아키텍처
- AWS · Azure · GCP DB 1:1 매핑
- Cloud SQL vs AlloyDB
- Multi-Zone HA · Read Replica · PITR
AWS · Azure · Google Cloud 데이터베이스 1:1 매핑
| 워크로드 분류 | AWS | Microsoft Azure | Google Cloud | 핵심 특징 |
|---|---|---|---|---|
| 관리형 RDBMS (OLTP) | Amazon RDS | Azure SQL / Flexible Server | Cloud SQL | MySQL · PostgreSQL · SQL Server 관리형 |
| 클라우드 네이티브 PG | Aurora PostgreSQL | Azure DB for PG Hyperscale | AlloyDB for PostgreSQL | 컴퓨트·스토리지 분리 · PG 4배↑ · 컬럼형 엔진 |
| 글로벌 분산 RDBMS | Aurora Global (단일 리전 쓰기) | Cosmos DB (NoSQL 기반) | Cloud Spanner | TrueTime 외부 일관성 · 멀티 리전 동시 쓰기 SQL |
| 초저지연 Wide-Column | Keyspaces / DynamoDB | Cosmos DB (Table/Cassandra) | Cloud Bigtable | 페타바이트 시계열·IoT · 단일 Row Key 밀리초 응답 |
| 서버리스 문서형 NoSQL | DynamoDB / DocumentDB | Cosmos DB (NoSQL API) | Firestore | 모바일·웹 실시간 동기화 · 계층형 JSON 문서 |
| 서버리스 DW (OLAP) | Amazon Redshift | Fabric DW / Synapse | BigQuery | 페타바이트 컬럼형 분석 · BQML · Vector Search |
Cloud SQL vs AlloyDB for PostgreSQL
리전 퍼시스턴트 디스크 기반의 표준 관리형 DB예요. Multi-Zone HA(Primary + Standby 자동 Failover), Read Replica 읽기 분산, WAL/바이너리 로그 기반 시점 복구(PITR)를 기본 제공해요.
컴퓨트와 분산 스토리지(Colossus 기반)를 완전히 분리해 표준 PostgreSQL 대비 트랜잭션 4배, 분석 쿼리 최대 100배(인메모리 Columnar Engine) 빠른 HTAP 엔진이에요.
- 자동 백업 & PITRWAL·Binary Log 활성화로 원하는 초 단위 시점으로 새 인스턴스 복원
- Multi-Zone HARegional 구성을 통해 Primary 장애 시 Standby 존으로 자동 Failover
- Read Replica / Pool읽기 트래픽을 복제본·리드 풀 노드로 분산해 Primary 부하 격리
- Auth Proxy 보안 접속IAM 인증 및 TLS 암호화 터널로 공인 IP 노출 없이 안전 연결
Database Selection Framework & HA 실습
7–8교시 · 자격증(PDE·PCDBE) 및 실무 아키텍처 핵심 의사결정 기준과 Lab 3
- 워크로드별 DB 의사결정 매트릭스
- Lab 3 · Cloud SQL HA & PITR
- AlloyDB 프로비저닝 & 컬럼형 엔진
요구사항 한 줄로 고르는 최적의 데이터베이스
| 비즈니스 요구사항 / 시험 키워드 | 선택할 서비스 | 핵심 판단 근거 (오답 함정 피하기) |
|---|---|---|
| 리전 단위 정형 트랜잭션 (MySQL / PG / SQL Server) | Cloud SQL | 기존 오픈소스·상용 RDBMS 100% 호환 및 가장 경제적인 관리형 OLTP |
| 고성능 PostgreSQL + 실시간 운영 분석(HTAP) + AI 벡터 | AlloyDB | Columnar Engine 내장 및 pgvector 가속으로 트랜잭션·분석 동시 처리 |
| 글로벌 멀티 리전 강일관성(ACID) + 무제한 수평 확장 SQL | Cloud Spanner | Cloud SQL은 리전 단일 쓰기 한계 → 글로벌 동시 쓰기 SQL은 Spanner 필수 |
| 초당 수십만 건 IoT·시계열·금융 틱 쓰기 + 밀리초 단건 조회 | Cloud Bigtable | SQL 조인 불필요, 단일 Row Key 기반 초고속 Wide-Column NoSQL |
| 모바일·웹 앱 직접 연결 + 오프라인 동기화 + JSON 문서 | Firestore | 클라이언트 SDK 실시간 리스너 및 서버리스 자동 스케일링 |
| 대규모 이력 데이터 SQL 집계 · BI 대시보드 · 머신러닝 | BigQuery | 운영 DB(OLTP)가 아닌 컬럼형 분석 DW(OLAP) — 초 단위 대용량 스캔 |
Google Cloud Database Selection 가이드GCDE · GCDBE 전체 서비스 그룹 그래프 보기
Lab 3 · Cloud SQL 고가용성(HA) · 복제 · PITR 실습
# 1. Multi-Zone HA + PITR Cloud SQL(PG) 생성
gcloud sql instances create commerce-pg \
--database-version=POSTGRES_15 \
--tier=db-custom-2-8192 --region=us-central1 \
--availability-type=REGIONAL \
--backup-start-time=02:00 \
--enable-point-in-time-recovery
# 2. Read Replica 추가 및 Failover 테스트
gcloud sql instances create commerce-pg-read \
--master-instance-name=commerce-pg \
--tier=db-custom-2-8192 --region=us-central1
gcloud sql instances failover commerce-pg
- availability-type=REGIONALPrimary와 Standby가 서로 다른 Zone에 동기 복제되어 자동 Failover 보장
- PITR 전제 조건자동 백업(backup-start-time)과 WAL 아카이빙이 함께 켜져 있어야 시점 복원 가능
- 1일차 핵심 요약Project/IAM 최소 권한 ➔ Cloud Storage 수명주기 ➔ 워크로드 맞춤 DB 선택
Lab 3-A · Cloud SQL Replication & PITR (skills.google)Lab 3-B · AlloyDB Fundamentals (skills.google)
Google Cloud Data & Database Engineer · 2일차
무중단 DB 이관과
Spanner · Bigtable.
오늘의
흐름
- 016R 마이그레이션 · DMS & Datastream CDC1–3교시 · 동종/이기종 무중단 이관 아키텍처 & Lab 4 (DMS)
- 02Cloud Spanner 글로벌 분산 DB & 스키마4–5교시 · TrueTime 외부 일관성 · Hotspot 방지 PK & Lab 5
- 03Cloud Bigtable Row Key 설계 & 대량 적재6–7교시 · Tall & Narrow 시계열 모델링 · cbt CLI & Lab 6
- 04Firestore 문서형 NoSQL & 운영 DB 종합8교시 · 컬렉션/서브컬렉션 설계 및 Day 1–2 DB 총정리
6R 마이그레이션 · DMS & Datastream CDC
1–3교시 · 다운타임 제로(Near-Zero Downtime)를 달성하는 데이터베이스 이관 아키텍처
- Migration Center · DMA
- Homogeneous vs Heterogeneous
- DMS vs Datastream 비교
- Lab 4 · DMS 무중단 이관
DB 마이그레이션 4단계와 동종 · 이기종 전략
- 1. Assess (진단)Migration Center & DMA로 원본 DB 스키마·확장 기능·적합도 스캔
- 2. Plan (계획)동종(Replatform) vs 이기종(Refactor) 결정 및 VPC Peering/VPN 설계
- 3. Deploy (복제)초기 전체 덤프(Full Dump) 후 실시간 CDC(Change Data Capture) 연속 동기화
- 4. Optimize (전환)Data Validation Tool(DVT) 정합성 검증 후 Cutover(Promote) 실행
스키마와 애플리케이션 SQL 변경 없이 관리형 엔진으로 이동해요. DMS가 초기 스냅샷과 실시간 바이너리 로그/WAL 복제를 자동 처리해요.
DMS Conversion Workspace와 Gemini 기반 AI 코드 변환으로 PL/SQL·저장 프로시저·데이터 타입을 PostgreSQL 호환 코드로 자동 변환해요.
헷갈리기 쉬운 두 CDC 도구: DMS vs Datastream
둘 다 원본 DB의 변경분(CDC)을 실시간으로 읽지만, 목적지가 운영 DB(OLTP)인지 분석 저장소(OLAP)인지가 달라요.
| 비교 기준 | Database Migration Service (DMS) | Datastream |
|---|---|---|
| 핵심 목적 | 운영 DB 무중단 이사 (이관 완료 후 타겟 승격) | 분석용 실시간 CDC 파이프라인 (지속 스트리밍 복제) |
| 목적지 (Target) | Cloud SQL, AlloyDB (운영 관계형 DB) | BigQuery, Cloud Storage (분석 DW · 데이터 레이크) |
| 원본 (Source) | MySQL, PostgreSQL, SQL Server, Oracle | Oracle, MySQL, PostgreSQL, SQL Server, Salesforce |
| 최종 단계 | Promote(Cutover)로 타겟 DB를 새 Primary로 승격 | BigQuery Storage Write API 병합으로 실시간 분석 유지 |
| AWS / Azure 대응 | AWS DMS (DB Migration) / Azure DMS | AWS DMS (to S3/Redshift) / Azure Data Factory CDC |
Lab 4 · DMS 기반 MySQL → Cloud SQL 무중단 이관
- Connection Profile원본 MySQL(IP·계정·binlog 확인) 및 목적지 접속 프로필 생성
- Continuous Job 생성VPC Peering 연결 구성 및 Continuous(Full Dump + CDC) 방식 선택
- 실시간 복제 & 검증초기 적재 완료 후 원본에 신규 INSERT 발생 시 Cloud SQL 자동 반영 확인
- Promote (Cutover)복제 지연(Replication Lag) 0 확인 후 타겟 인스턴스를 독립 Primary로 승격
binlog_format=ROW)과 GTID(또는 충분한 로그 보관 기간)가 켜져 있어야 CDC가 누락 없이 동작해요.Lab 4-A · Continuous DMS Job (skills.google)Lab 4-B · RDS MySQL to Cloud SQL (skills.google)
Cloud Spanner 글로벌 분산 DB & 스키마
4–5교시 · RDBMS의 강력한 트랜잭션(ACID·SQL)과 NoSQL의 무제한 수평 확장을 결합한 아키텍처
- TrueTime API · External Consistency
- Split 자동 분할 & Hotspot 방지 PK
- Interleaved Table
- Lab 5 · Spanner DDL & Query Plan
왜 Spanner인가: TrueTime 외부 일관성과 수평 확장
전 세계 데이터센터의 하드웨어 원자시계와 GPS로 시간 오차를 수 밀리초 이내로 묶어, 글로벌 분산 락 없이도 직렬화 가능한 강한 일관성(Strong Consistency)을 보장해요.
데이터가 커지거나 트래픽이 몰리면 Primary Key 정렬 범위를 기준으로 데이터를 Split 단위로 자동 분할해 여러 컴퓨트 노드에 분산 배치해요.
Paxos 합의 알고리즘으로 멀티 리전 쿼럼에 동기 복제하여, 리전 하나가 통째로 멈춰도 다운타임과 데이터 유실(RPO=0) 없이 즉시 서비스를 이어가요.
Spanner 스키마 핵심: Hotspot 방지와 Interleaved Table
나쁜 예: 순차 증가 키 (Auto-Increment / Timestamp 선두)
Primary Key를 1, 2, 3... 또는 CreatedAt 타임스탬프 선두로 잡으면 모든 신규 INSERT가 항상 마지막 Split(단일 서버 노드) 하나에만 집중되어 심각한 쓰기 병목(Hotspot)이 발생해요.
좋은 예: UUID v4 · Hash Prefix · 복합키 순서 변경
UUID v4, 해시 프리픽스(ShardId), 또는 카디널리티가 높은 (UserId, OrderDate) 순으로 키를 구성해 쓰기 트래픽을 모든 노드의 Split에 고르게 분산해요.
INTERLEAVE IN PARENT): 부모(Customers)와 자식(Orders) 행을 같은 Split에 물리적으로 나란히 저장(Co-location)해 네트워크 홉 없는 초고속 조인을 수행해요.Lab 5 · Spanner 인터리빙 스키마 & 실행 계획 실습
-- 1. 부모 테이블 (분산 키 사용)
CREATE TABLE Customers (
CustomerId STRING(36) NOT NULL,
Name STRING(100)
) PRIMARY KEY (CustomerId);
-- 2. 자식 테이블 (부모 Split 동반 배치)
CREATE TABLE Orders (
CustomerId STRING(36) NOT NULL,
OrderId STRING(36) NOT NULL,
OrderTotal NUMERIC
) PRIMARY KEY (CustomerId, OrderId),
INTERLEAVE IN PARENT Customers ON DELETE CASCADE;
- 복합 PK 상속 규칙자식 테이블 PK는 반드시 부모 테이블의 PK(CustomerId)를 맨 앞 접두어로 포함해야 해요
- Query Execution Plan콘솔의 Query Plan 시각화에서 네트워크 셔플 없이 Local Join으로 실행되는지 확인
- gcloud spanner CLI인스턴스·DB 생성부터 DDL 반영, SQL 조회까지 CLI로 자동화
Lab 5-A · Spanner Fundamentals (skills.google)Lab 5-B · Schemas & Query Plans (skills.google)
Cloud Bigtable Row Key 설계 & 대량 적재
6–7교시 · 페타바이트급 시계열·IoT·금융 데이터를 한 자릿수 밀리초(ms)에 처리하는 Wide-Column NoSQL
- Bigtable vs BigQuery
- Tall & Narrow 모델링
- Row Key Hotspot 방지
- Lab 6 · cbt CLI & 시계열 조회
Cloud Bigtable 아키텍처와 BigQuery와의 역할 분담
Bigtable은 컴퓨트 노드(태블릿 서버)와 Colossus 스토리지(SSTable)가 분리되어 있어 노드 추가만으로 처리량이 선형 확장돼요.
| 비교 항목 | Cloud Bigtable (NoSQL OLTP · 시계열) | BigQuery (서버리스 DW · OLAP) |
|---|---|---|
| 주 워크로드 | IoT 센서, 실시간 주가/클릭스트림, 피처 스토어, 개인화 추천 | 전사 BI 리포팅, 대규모 로그 SQL 집계, 머신러닝(BQML) |
| 응답 지연 / 처리량 | 한 자릿수 밀리초(ms) · 초당 수십만~수백만 읽기/쓰기 | 초~분 단위 · 대용량 테이블 풀/파티션 스캔 |
| 접근 패턴 | 단일 Row Key 조회(Lookup) 및 사전순 Row Key 범위 스캔(Range Read) | 표준 SQL 조인, GROUP BY, 윈도우 함수, 벡터 검색 |
| 데이터 변형(Mutation) | 실시간 셀 단위 고속 덮어쓰기·추가 최적화 | 배치/스트리밍 Append 최적화 (잦은 단건 UPDATE 비효율) |
성능의 90%를 결정하는 Bigtable Row Key 설계
나쁜 예: 타임스탬프 선두 · 낮은 카디널리티 · Fat Row
20261110#Bus101처럼 타임스탬프를 맨 앞에 두면 최신 쓰기가 한 노드에 몰려 Hotspot이 생겨요. 한 행에 수만 개 이벤트를 우겨 넣는 Wide(Fat) 구조도 피해야 해요.
좋은 예: 필드 결합 + 역순 타임스탬프 (Tall & Narrow)
MTA#B63#N#9223370399...(운수사#노선#방향#역순타임스탬프)처럼 자주 함께 조회하는 조건을 앞에 두고, 최신순 조회가 필요하면 MAX_LONG - timestamp 역순값을 붙여요.
Lab 6 · cbt CLI 기반 시계열 Row Key 조회 실습
# 1. cbt CLI 환경파일(.cbtrc) 자동 구성
echo project = $PROJECT_ID > ~/.cbtrc
echo instance = nyc-transit >> ~/.cbtrc
# 2. 테이블 생성 및 컬럼 패밀리(cf) 추가
cbt createtable bus-data
cbt createfamily bus-data cf
# 3. 특정 버스 노선(M86-SBS)의 시계열 범위 스캔
cbt read bus-data prefix=MTA/M86-SBS/ count=5
# 4. 특정 시각·차량 단건 Row Key 즉시 조회
cbt lookup bus-data "MTA/M86-SBS/1496275200000/NYCT_5824"
- prefix 범위 스캔Row Key가 사전순(Lexicographical)으로 정렬되어 있어 prefix 지정만으로 특정 노선 전체를 밀리초에 읽어요
- Tall & Narrow 구조버스 위치 측정값 1건을 행(Row) 1개로 저장해 확장성과 스캔 효율 극대화
- Dataflow 대량 적재Cloud Storage의 SequenceFile/Parquet 데이터를 Dataflow 템플릿으로 고속 병렬 적재
Lab 6-A · Designing & Querying Bigtable Schemas (skills.google)Lab 6-B · Populating a Bigtable Instance (skills.google)
Firestore 문서형 NoSQL & 운영 DB 종합
8교시 · 모바일·웹 서버리스 문서 DB 모델링과 Day 1–2 데이터베이스 파트 총정리
- Collection · Document · Subcollection
- Security Rules · 오프라인 동기화
- Day 1–2 운영 DB 총정리 & Day 3 예고
Firestore 문서 모델링과 Day 1–2 운영 DB 총정리
문서(최대 1MB JSON)는 컬렉션에 속하며, 하위 배열이 계속 커지면 Subcollection으로 분리해 조회 비용을 최적화해요.
백엔드 없이도 모바일·웹 SDK가 Security Rules 검증을 거쳐 직접 구독하고 오프라인 변경분을 자동 동기화해요.
자동 인덱스와 복합 인덱스를 강제해 전체 컬렉션이 1억 건이어도 결과 10건 조회 시간은 항상 일정해요.
- Cloud SQL / AlloyDB리전 정형 RDBMS · HTAP 고성능 PG
- DMS / Datastream무중단 DB 이사 · 실시간 분석 CDC
- Spanner / Bigtable글로벌 SQL · 초고속 시계열 NoSQL
- Day 3 → BigQuery DW모든 데이터가 모이는 분석·AI 허브
Google Cloud Data & Database Engineer · 3일차
BigQuery와
거버넌스 · In-DB AI.
오늘의
흐름
- 01BigQuery 아키텍처 · 엔터프라이즈 DWLab 7 · Building Enterprise DW in BigQuery with SQL
- 02파티셔닝 · 클러스터링 & LakehouseLab 8 · Partitioning, Clustering & Cost Optimization
- 03Knowledge Catalog 거버넌스 & BigQuery MLLab 9 · Training & Evaluating BQML Classification Model
- 04Gemini in BigQuery & Dataform ELTAI SQL 생성 · Data Canvas · SQLX 워크플로
Google Cloud Data & Database Engineer · 4일차
실시간 스트리밍과
Gemini RAG 캡스톤.
오늘의
흐름
- 01Cloud Pub/Sub 실시간 메시징Lab 10 · Streaming Events to BigQuery with Pub/Sub
- 02Dataflow (Apache Beam) 스트리밍 ETLLab 11 · Streaming Pipeline with Dataflow Templates
- 03BigQuery Vector Search & Gemini RAGLab 12 Capstone · Building RAG Search with BigQuery & Gemini
- 04엔드투엔드 아키텍처 회고 & 자격증 로드맵PDE · PCDBE 핵심 의사결정 기준 정리