데이터 저장의 세 가지 형태
대부분의 데이터베이스는 세 가지 계열에 속한다. 제품을 외울 필요는 없다 — 어떤 형태가 당신의 문제에 맞는지 알아보면 된다.
| 유형 | 예시 | 적합한 용도 | 트레이드오프 |
|---|---|---|---|
| 관계형 (SQL) | PostgreSQL, MySQL, SQLite | 관계가 있는 구조화된 데이터; 돈이나 정확성이 중요한 모든 것 | 스키마를 미리 설계해야 한다; 쓰기를 아주 크게 확장하기는 더 어렵다 |
| 문서형 / NoSQL | MongoDB, Firestore, DynamoDB | 유연하거나 중첩된 데이터, 빠른 반복, 다양한 레코드 형태 | 일관성 없는 데이터를 만들기 쉽다; 관계와 리포팅이 어색해진다 |
| 키-값 | Redis, Memcached, Cloudflare KV | 캐싱, 세션, 카운터, 알려진 키로 빠른 조회 | 내용으로 쿼리할 수 없다; 보통 신뢰의 원천(source of truth)은 아니다 |
프로젝트의 90%에 적합한 기본값: 관계형 데이터베이스(Postgres)로 시작하라. 성숙하고 예측 가능하며, 구조를 강제하고, 진짜 앱이 필연적으로 키워나가는 관계를 잘 다룬다. 데이터가 정말로 형태가 없을 때 문서형 저장소를 꺼내고, 키-값 저장소는 보조 계층(캐싱)으로 쓰되 주 저장소로는 쓰지 말라.
피해야 할 함정은 분위기로 고르는 것이다. "NoSQL이 확장성이 더 좋다"는 말은 대부분의 앱이 결코 닿지 않는 좁은 문제 집합에서만 참이고, 그조차도 데이터를 신뢰할 수 있게 만드는 일관성 보장을 포기하는 대가를 치른다. 시스템 설계 영상에서 가장 인상적으로 들리는 형태가 아니라, 당신의 데이터에 맞는 형태를 골라라. 확신이 서지 않으면 관계형이 안전한 선택이다 — 캐시나 문서형 저장소는 나중에 언제든 더할 수 있지만, 엉킨 NoSQL 데이터 모델을 풀어내는 일은 고통스럽다.