Overview
SQL, NoSQL, NewSQL — Unity + C# 관점
Section titled “SQL, NoSQL, NewSQL — Unity + C# 관점”Unity 게임에서 DB를 선택할 때
중요한 건 “SQL이냐 NoSQL이냐”보다
어떻게 요청되고, 어떻게 연결되고, 어떻게 처리되는가다.
이 문서는
DB 종류를 통신 패턴과 서버 구조 관점에서 정리한다.
1. 먼저 큰 그림
Section titled “1. 먼저 큰 그림”Unity 클라이언트는
DB에 직접 접근하지 않는다.
항상 구조는 다음과 같다.
Unity Client
→ API / Game Server
→ Database
따라서 DB 선택은
Unity가 아니라 서버의 동작 방식에 영향을 준다.
2. SQL / NoSQL / NewSQL 개념 요약
Section titled “2. SQL / NoSQL / NewSQL 개념 요약”SQL (관계형 DB)
Section titled “SQL (관계형 DB)”- 고정된 스키마
- 트랜잭션 중심
- ACID 보장
- 예: MySQL, PostgreSQL, SQL Server
- 유연한 스키마
- 문서 / 키-값 / 컬럼 / 그래프
- 수평 확장에 강함
- 예: MongoDB, DynamoDB, Redis
NewSQL
Section titled “NewSQL”- SQL 인터페이스 유지
- 분산 환경에서 수평 확장
- 강한 일관성 유지
- 예: Spanner, CockroachDB, TiDB
3. 대화 포인트 1 — 동기 vs 비동기
Section titled “3. 대화 포인트 1 — 동기 vs 비동기”3.1 동기 처리 중심 DB (전통적 SQL)
Section titled “3.1 동기 처리 중심 DB (전통적 SQL)”특징:
- 요청 하나 = 쿼리 하나
- 결과를 받을 때까지 대기
- 커넥션 점유 시간이 길어질 수 있음
서버 흐름:
API 요청
→ DB 쿼리 실행
→ 결과 수신
→ 응답 반환
문제점:
- 트래픽 증가 시
- DB 커넥션 고갈
- 응답 지연
- Unity 요청이 몰리면 병목 발생
Unity 관점 체감:
- 로그인/저장 시 딜레이
- 동시 접속 증가 시 서버 불안정
3.2 비동기 처리에 적합한 DB (NoSQL 계열)
Section titled “3.2 비동기 처리에 적합한 DB (NoSQL 계열)”특징:
- 요청이 빠르게 반환
- 이벤트 기반 처리에 적합
- 일부 일관성 희생 가능
서버 흐름:
API 요청
→ DB 쓰기 요청
→ 즉시 반환
→ 후처리/집계는 비동기
Unity 관점 체감:
- 응답 빠름
- “나중에 반영” 구조 허용 시 안정적
3.3 NewSQL의 접근
Section titled “3.3 NewSQL의 접근”특징:
- SQL처럼 사용
- 내부는 분산 처리
- 동기 트랜잭션이지만 확장성 높음
의미:
- “동기 처리의 안정성” + “확장성”을 동시에 노림
단점:
- 비용
- 운영 복잡도
- 클라우드 종속 가능성
4. 대화 포인트 2 — 요청 수 vs 연결 수
Section titled “4. 대화 포인트 2 — 요청 수 vs 연결 수”4.1 요청 수(Request Rate)
Section titled “4.1 요청 수(Request Rate)”- Unity 클라이언트 수
- 초당 API 호출 횟수
- 이벤트 발생 빈도
예:
- 초당 점수 제출 5,000건
- 로그인 요청 10,000건
요청 수가 많아지면:
- 서버는 메시지 큐 / 비동기 처리 필요
- DB는 쓰기 패턴 최적화 필요
4.2 연결 수(Connection Count)
Section titled “4.2 연결 수(Connection Count)”DB에서 진짜 문제는
요청 수가 아니라 동시에 열린 연결 수다.
SQL DB 특징:
- 연결 1개 = 리소스 점유
- 커넥션 풀 크기 한계 존재
문제 상황:
- Unity 요청 폭증
- API 서버가 DB 연결을 오래 잡고 있음
- 커넥션 풀 고갈 → 전체 장애
4.3 NoSQL이 연결 수에 강한 이유
Section titled “4.3 NoSQL이 연결 수에 강한 이유”- 요청 단위 처리
- 짧은 연결
- 내부적으로 분산 처리
결과:
- 많은 요청을 적은 연결로 처리 가능
- Burst 트래픽에 강함
4.4 NewSQL의 해결 방식
Section titled “4.4 NewSQL의 해결 방식”- 내부적으로 연결을 분산 노드에 분배
- 클라이언트는 SQL처럼 사용
- 서버는 확장된 DB 클러스터에 연결
즉:
- 연결 수 문제를 DB가 떠안음
5. Unity 게임에서 자주 쓰는 조합
Section titled “5. Unity 게임에서 자주 쓰는 조합”SQL이 잘 맞는 경우
Section titled “SQL이 잘 맞는 경우”- 계정 / 결제 / 정합성 중요한 데이터
- 트랜잭션 필수
- 요청 빈도가 상대적으로 낮음
NoSQL이 잘 맞는 경우
Section titled “NoSQL이 잘 맞는 경우”- 플레이 로그
- 세션 데이터
- 랭킹 스냅샷
- 이벤트 기록
NewSQL이 잘 맞는 경우
Section titled “NewSQL이 잘 맞는 경우”- 글로벌 서비스
- 강한 일관성 + 대규모 트래픽
- 비용 감당 가능할 때
6. 실무에서의 현실적인 결론
Section titled “6. 실무에서의 현실적인 결론”- Unity 게임 백엔드는
- SQL 하나로 끝나는 경우는 드물다
- 보통 구조:
- SQL + NoSQL 혼용
- 메시징/비동기 처리 병행
중요한 질문은 이것이다.
“이 데이터는
지금 당장 정확해야 하는가,
아니면 빠르게 쌓이면 되는가?“
7. 한 줄 요약
Section titled “7. 한 줄 요약”- SQL: 정확하지만 연결에 민감
- NoSQL: 빠르고 확장에 강함
- NewSQL: 둘 다 잡으려는 고급 선택지
Unity 관점에서 DB 선택은
데이터 성격과 트래픽 패턴의 문제다.