빅쿼리(BigQuery)는 어떤 DB인가?
서비스가 성장할수록 데이터는 폭발적으로 늘어난다.
트랜잭션 처리(DB에 기록하는 것)는 MySQL·PostgreSQL 같은 RDB로 충분하지만,
데이터 분석(대량 데이터 집계·리포팅)을 같은 DB에서 처리하기 시작하면 금방 한계가 보인다.
이 지점에서 등장하는 대표적인 선택지가 Google BigQuery다.
SQL 문법을 사용하지만, 내부 구조와 목적은 우리가 익숙한 RDBMS와 다르다.
BigQuery는 트랜잭션 DB가 아니다
가장 먼저 짚어야 하는 사실:
BigQuery는 MySQL/PostgreSQL 같은 트랜잭션 DB(OLTP)가 아니다.
BigQuery는 대규모 데이터 분석을 위해 설계된 컬럼 기반 데이터 웨어하우스(OLAP)다.
목적 자체가 다르다.
목적도구
| 사용자 로그인/주문/결제 등 실시간 트랜잭션 처리 | MySQL, PostgreSQL |
| 수억·수십억 건 데이터에서 집계/패턴 분석/리포팅 | BigQuery |
업무적으로 구분하면 이렇게 된다:
- 애플리케이션은 MySQL에서 데이터를 기록하고
- 분석 플랫폼은 BigQuery에서 데이터를 읽고 요약한다
BigQuery가 빠른 이유: 컬럼형 저장과 병렬 처리
BigQuery는 데이터를 컬럼 단위로 저장한다.
예를 들어 country, created_at, revenue 3개의 컬럼이 있을 때,
revenue만 집계하는 쿼리는 해당 컬럼만 읽는다.
일반 RDBMS(행 기반 저장)와 다르게
불필요한 컬럼 읽지 않아도 되므로 속도도 빨라지고 비용도 줄어든다.
또한 BigQuery는 기본적으로 병렬 분산 처리가 자동이다.
노드 수를 설정하거나 확장할 필요가 없다.
데이터가 많아질수록 내부에서 그냥 더 큰 클러스터를 붙여 처리한다.
집약하면 BigQuery의 성능 비밀은 두 가지다:
- 컬럼 기반 저장
- 자동 병렬 처리
서버를 운영할 필요가 없다
MySQL을 운영하면 고민해야 하는 것:
- CPU/메모리 스펙
- 인덱스 최적화
- 쿼리 튜닝
- 샤딩 확장
- 스토리지 관리
BigQuery는 전부 필요 없다.
서버리스다. 스토리지도 컴퓨팅도 구글이 알아서 확장한다.
사용자가 신경 쓸 건 오직 두 가지:
- 데이터를 넣는다
- SQL을 날린다
BigQuery 비용 모델: 저장은 싸고, 조회가 비싸다
다른 DB들과 확연히 다른 부분.
- 저장 비용 → 저렴함
- 쿼리 비용 → 스캔한 데이터 양 기준으로 과금
그래서 아래가 실무에서 흔한 최적화 포인트다:
- SELECT * 금지
- 파티션 / 클러스터 사용
- 필요한 컬럼만 스캔
- FILTER 조건을 파티션키에 맞춰 설계
- 미리 집계한 마트(mart) 테이블 운용
MySQL처럼 CPU 점유율로 장애가 오는 게 아니라
BigQuery는 비효율적인 쿼리 = 비용 폭탄의 문제가 생긴다.
파티션과 클러스터는 선택이 아니라 필수
BigQuery 성능/비용을 결정하는 가장 핵심 개념.
- 파티션(partition): 테이블을 날짜/범주 기준으로 물리적으로 잘라두는 기능
- 클러스터(cluster): 파티션 내부를 특정 컬럼 기준으로 정렬해두는 기능
예시:
- created_at 기준으로 파티션
- 파티션 내부를 country, platform으로 클러스터링
이렇게 설계하면
WHERE created_at >= '2025-12-01'
AND country = 'US'
같은 쿼리는 스캔량이 극적으로 줄어든다.
BigQuery를 쓰면 좋은 시나리오
아래 중 하나라도 해당하면 BigQuery는 적합하다.
- GA(Google Analytics)4 로그 분석
- 플레이어/유저 행동 데이터 분석
- 광고/매출 리포팅
- 리텐션/코호트 분석
- 통합 로그 데이터 레이크 구축
- 머신러닝/추천 시스템용 대량 데이터 피쳐 생성
일반 RDBMS는 데이터를 기록하기 위한 DB이고
BigQuery는 규모가 커진 데이터를 읽고 가공하기 위한 DB다.
BigQuery를 적대적으로 대해야 하는 상황도 있다
장점만 있는 건 아니다.
- 실시간 트랜잭션 업데이트·JOIN이 많으면 부적합
- UPDATE/DELETE가 상대적으로 느리고 비용도 큼
- 조인 테이블 수가 지나치게 많을 때 비효율적
- 개발자가 비용 개념 없이 쿼리 작성하면 바로 폭탄
빅쿼리는 도구가 아니라 _전략_이다.
“그냥 SQL 비슷하네”라고 접근하면 손해보기 쉽다.
결론
빅쿼리는 MySQL을 대체하는 DB가 아니다.
MySQL 이후 데이터가 커졌을 때 해결하는 DB다.
- SQL을 지원하지만 내부 방식은 완전히 다르다
- 저장은 싸고, 읽는 게 비싸다
- 파티션/클러스터 제대로 설계하면 비용과 속도가 갈린다
- 분석/리포팅/머신러닝 기반 데이터 파이프라인에 최적화된 플랫폼이다
데이터 기반 비즈니스를 운영한다면
어느 시점에서든 BigQuery를 이해하고 활용할 줄 아는 능력은 선택이 아니라 필수가 된다.
'DataBase' 카테고리의 다른 글
| DB 참조 무결성 제약 (feat. ON DELETE, ON UPDATE) (5) | 2025.01.19 |
|---|