1. 테이블 설계 - 정규화와 비정규화의 균형 잡기
DB 설계의 첫걸음은 정규화이다. 데이터 중복을 줄이고, 무결성을 지키기 위한 과정이다.
•
1NF (제1정규형): 컬럼은 원자값으로 분해한다 (배열 형태로 저장하지 않기)
•
2NF, 3NF: 종속성을 분리해서 중복 데이터 최소화
경우에 따라 비정규화가 필요한 경우도 많다.
•
조회 속도가 중요한 테이블에서는 일부 컬럼 중복을 허용해 JOIN을 줄인다.
•
로그성 데이터는 정규화보다 빠른 적재와 조회가 우선이다.
⇒ 설계 초기엔 정규화, 서비스가 성장하면서 성능 병목이 생길 때 부분 비정규화를 고려한다.
2. PK, FK, 인덱스 설계 - 관계를 명확히, 성능은 빠르게
•
PK (Primary Key): 테이블의 고유값, 보통 AUTO_INCREMENT 나 UUID 사용
•
FK (Foreign Key): 테이블 간 관계를 명확하게 설정하지만, 트래픽 많은 테이블에서는 FK 제약 조건을 생략하기도 한다(애플리케이션 레벨에서 무결성 관리).
⇒ 인덱스는 조회용으로 필수지만, 과하면 쓰기 성능 저하를 부른다. 조회가 잦은 컬럼 위주로 선별해서 생성하자.
3. 데이터 타입 선택 - 작은 차이가 큰 차이로
•
INT vs BIGINT: 데이터량에 따라 선택 (유저 ID는 미래 성장성을 감안해 BIGINT 고려)
•
VARCHAR 길이: 실제 최대 값에 맞게 설정 (무조건 길게 잡으면 메모리 낭비)
•
DATETIME vs TIMESTAMP : 타임존 처리와 범위를 고려해 선택
⇒ 실무에서는 데이터 양이 늘어날 때 어떤 영향이 생길지 미리 생각하고 타입을 선택해야 한다.
4. 분석을 위한 설계 - 조회 패턴을 예측
DB 설계는 단순히 데이터 저장이 아니라, 어떻게 조회할 것인가를 기준으로 해야 한다.
•
최근 데이터 조회가 많은 경우, 날짜 컬럼에 인덱스 부여
•
유저별 데이터 조회가 많다면 user_id 인덱스는 필수
•
복합 조회 (예: 날짜 + 상태값)는 복합 인덱스로 튜닝
⇒ 설계 단계에서 가장 자주 나올 쿼리를 먼저 적어보고, 그에 맞는 인덱스와 테이블 구조를 맞추는 게 효율적이다.
5. 통계와 로그 테이블 - 분리 저장이 원칙
•
서비스용 테이블과 통계용 테이블은 분리해 과부하 방지
•
실시간 조회가 필요 없는 로그 데이터는 별도 저장소(예: Elasticsearch, S3)에 적재 고려
⇒ 통계용 테이블은 집계 주기(일별, 주별)에 맞춰 별도로 설계하면 메인 테이블의 부하를 줄일 수 있다.
DB 설계는 결국 "데이터를 어떻게 읽을 것인가"에 대한 고민이다. 테이블을 만들기 전에 조회 패턴과 성장 시나리오를 먼저 상상해 보는 게 설계의 출발점이라고 생각한다.