NoSQL이 뭔지, RDBMS와 뭐가 다른지, 4가지 종류와 각 예시(Redis, MongoDB 등)를 간단히 정리했습니다.
NoSQL이란
"Not Only SQL"의 줄임말로, 관계형 데이터베이스(RDBMS)처럼 정해진 테이블/행-열 구조를 따르지 않는 데이터베이스를 통틀어 부르는 말입니다.
RDBMS와 NoSQL 비교
- RDBMS (예: MySQL) - 스키마 고정, 테이블 형태로 저장
| 1 | 철수 | 1001 |
- NoSQL (예: MongoDB, 문서형) - 스키마 자유, 필드가 문서마다 달라도 됨.
* 아래는 이해를 돕기 위해 JSON으로 표현한 것일 뿐, 실제 저장 형식은 DB마다 다릅니다(MongoDB는 내부적으로 BSON이라는 이진 포맷 사용).
{ "id": 1, "name": "철수", "orders": [1001, 1002] }RDBMS는 구조가 엄격한 대신 데이터 정합성(트랜잭션, 관계)에 강하고, NoSQL은 구조가 유연한 대신 빠른 조회와 수평 확장(서버를 여러 대로 늘리기)에 강합니다.
NoSQL 4가지 종류
- Key-Value 형: 키 하나에 값 하나. 가장 단순하고 빠름. 예) Redis — SET user:1 "철수" 처럼 키 하나로 값 하나를 즉시 조회
- 문서(Document) 형: JSON 같은 문서 통째로 저장. 문서마다 필드가 달라도 됨. 예) MongoDB — 사용자마다 주소, 취미 등 저장하는 필드 개수가 달라도 상관없음
- 컬럼(Column-family) 형: 대량의 데이터를 컬럼 단위로 저장해서 특정 컬럼만 빠르게 조회. 예) Cassandra — 로그, 시계열 데이터처럼 데이터량이 매우 많을 때
- 그래프(Graph) 형: 데이터 자체보다 데이터 "사이의 관계"를 저장. 예) Neo4j — SNS 친구 관계, 추천 시스템처럼 연결 관계가 중요한 경우
* 그래프(Graph) 형 - 추가 설명
데이터: 하늘, 민수, 지영, 재석이라는 4명의 사용자가 있고, 서로 친구 관계를 맺고 있습니다.
(하늘) --친구--> (민수)
(하늘) --친구--> (지영)
(민수) --친구--> (재석)
(지영) --친구--> (재석)이걸 RDBMS로 저장하려면 "친구관계" 테이블을 따로 만들어서 user_id, friend_id 컬럼에 관계를 하나하나 행으로 저장해야 하고, "친구의 친구"를 찾으려면 테이블을 여러 번 JOIN해야 합니다. 관계가 몇 단계만 깊어져도 JOIN이 급격히 늘어나서 느려집니다.
그래프 DB(Neo4j)는 애초에 "노드(사람)"와 "관계(친구)"를 데이터 구조 자체로 저장하기 때문에, 이런 질의가 훨씬 자연스럽고 빠릅니다.
// 하늘의 친구의 친구를 찾기 (친구 추천에 활용)
MATCH (me:User {name: "하늘"})-[:FRIEND]->()-[:FRIEND]->(recommend)
WHERE NOT (me)-[:FRIEND]->(recommend)
RETURN recommend이 쿼리 하나로 "하늘과 직접 친구는 아니지만, 친구를 통해 연결된 사람"을 바로 찾아냅니다. 이게 바로 페이스북/인스타그램 같은 SNS의 "알 수도 있는 사람" 추천이나, 넷플릭스의 "이 콘텐츠를 본 사람이 함께 본 콘텐츠" 추천 같은 기능의 기본 원리입니다. 관계가 몇 단계로 이어지든, RDBMS의 JOIN 지옥 없이 관계를 타고 넘어가며 탐색할 수 있다는 게 그래프 DB의 강점입니다.
왜 쓰는가
- 속도: 구조가 단순해서 조회/저장이 빠름 (Redis는 메모리 기반이라 더 빠름)
- 유연한 스키마: 데이터 형태가 자주 바뀌거나 정형화하기 어려울 때 유리
- 수평 확장: 서버를 여러 대로 늘려서 데이터를 나눠 저장하기에 RDBMS보다 구조적으로 적합
마무리
NoSQL은 RDBMS를 대체하는 개념이 아니라, 상황에 맞는 도구를 하나 더 갖는 것에 가깝습니다. 정확한 트랜잭션과 관계가 중요한 데이터(주문, 결제 내역)는 RDBMS에, 빠른 조회나 유연한 구조가 필요한 데이터(세션, 캐시, 로그)는 NoSQL에 나눠 쓰는 게 실무에서 흔한 조합입니다.