EP 7: ‘Join’ 세금 vs. ‘Storage’ 세금
Source: Dev.to
SQL vs NoSQL Trade‑offs
시스템 설계에서 SQL과 NoSQL을 논할 때는 문법을 넘어 핵심적인 트레이드‑오프를 살펴봅니다. 실제 시스템에서는 쿼리 언어가 마음에 들어서가 아니라 트래픽 처리 방식, 일관성, 장애 복구 방식 때문에 데이터베이스를 선택합니다.
- SQL (정규화) – 중복을 최소화합니다. 사용자의 이름을 변경하면 한 곳만 수정하면 됩니다. 여기서 발생하는 “세금”은 조인에 있습니다: 대시보드가 다섯 개 테이블의 데이터를 필요로 하면, 읽는 시점에 데이터베이스가 무거운 작업을 수행해 데이터를 엮어야 합니다.
- NoSQL (비정규화) – 중복을 허용합니다. 사용자의 이름을 다섯 개 다른 문서 컬렉션에 저장할 수 있습니다. 여기서의 “세금”은 스토리지와 업데이트 복잡도입니다. 읽기는 이미 “미리 조인된” 상태라 매우 빠르지만, 이름이 바뀔 경우 여러 곳을 동시에 업데이트해야 합니다.
스스로에게 물어보세요: 앱이 읽기 위주인가, 쓰기 위주인가? 수백만 번 읽히고 한 번만 쓰이는 소셜 미디어 피드라면, NoSQL의 읽기‑최적화 형식이 보통 더 유리합니다.
CAP Theorem
CAP 정리는 분산 시스템에 대한 궁극적인 현실 검증 도구입니다.
- 일관성 (Consistency, C): 모든 노드가 같은 데이터를 동시에 본다.
- 가용성 (Availability, A): 모든 요청이 응답을 받는다(설령 오래된 데이터라 하더라도).
- 파티션 내성 (Partition Tolerance, P): 노드 간 네트워크가 끊겨도 시스템이 계속 동작한다.
분산 환경에서는 P를 반드시 선택해야 합니다. 그러면 CP(SQL‑같은 엄격함)와 AP(NoSQL‑같은 속도) 중 하나를 고르게 됩니다.
- SQL (CP): 은행이나 재고 관리에 이상적입니다. 잘못된 잔액을 보여주는 것보다 서비스가 일시적으로 중단되는 것이 낫습니다.
- NoSQL (AP): 게시물에 대한 “좋아요”와 같이 작은 불일치(예: 100 vs. 102 좋아요)가 허용 가능한 경우에 적합합니다.
이 트레이드‑오프는 고수준 설계 면접에서 가장 큰 영향을 미치는 요소 중 하나입니다.
Scaling
SQL Scaling (Vertical)
수직 확장은 같은 차의 자동차에 더 큰 엔진을 장착하는 것과 같습니다. 가장 큰 서버의 한계에 도달하면 수동 샤딩을 해야 하는데, 이는 설계 복잡성의 악몽이 됩니다.
NoSQL Scaling (Horizontal)
NoSQL 데이터베이스는 설계 자체가 샤딩을 염두에 두고 만들어졌습니다. 저렴한 서버(노드)를 더 추가하면 클러스터에 자동으로 데이터가 분산됩니다.
Real‑World Use Cases
Financial Systems (SQL)
한 푼이라도 빠지면 법적 재앙이 될 수 있는 경우, SQL이 유일한 실질적인 선택입니다. 금융 시스템은 ACID 준수를 통해 트랜잭션이 완전히 성공하거나 전부 실패하도록 보장하며, “중간 상태”가 존재하지 않게 합니다.
예시: JPMorgan Chase는 핵심 원장에 대해 고도로 튜닝된 관계형 데이터베이스(PostgreSQL 또는 Oracle)를 사용합니다. 엄격한 스키마와 강한 일관성이 필수이며, 잔액은 즉시 정확해야 하고 “점진적으로” 맞춰지는 것이 허용되지 않습니다.
Social Media Feeds (NoSQL)
소셜 미디어는 읽기 비중이 높고 텍스트, 이미지, 태그, 반응 등 방대한 비정형 데이터를 다룹니다. NoSQL은 수평 확장이 용이하고 미리 계산된 문서를 밀리초 단위로 제공할 수 있어 강점을 발휘합니다.
예시: Instagram은 하이브리드 방식을 사용하지만 피드에 대해서는 NoSQL‑스타일 아키텍처를 채택합니다. 스크롤할 때 앱은 사진, 캡션, 좋아요 수가 포함된 미리 계산된 문서를 가져와 여러 테이블을 조인하는 복잡성을 피합니다.
Key‑Value Stores (Redis)
몇 분 동안만 필요한 임시, 초고속 저장소가 필요할 때가 있습니다. Redis와 같은 키‑값 NoSQL 스토어는 사용자 세션, 쇼핑 카트, 리더보드에 최적입니다. 세션 토큰을 Redis에 저장하면 매 요청마다 메인 SQL 데이터베이스에 접근할 필요가 없습니다.
예시: Riot Games(League of Legends)와 같은 게임 플랫폼은 실시간 리더보드와 플레이어 세션 관리를 위해 NoSQL 키‑값 스토어를 사용합니다. 수천 명의 플레이어가 동시에 매치를 마치고 즉시 순위가 업데이트되어야 하는데, 전통적인 SQL 락의 지연 없이 처리됩니다.