3.6 KiB
id, created, tags
| id | created | tags |
|---|---|---|
| RDBMS vs NoSQL 20260420 | 2026-04-20 08:43 |
DB에는 크게 RDBMS와 NoSQL 두가지의 범주가 있음. 둘 다 데이터베이스를 구축하기위한 방법론의 개념이고 상호간에 차이점들이 존재한다.
하지만 데이터베이스라면 당연히 데이터 정합성(Data Consistency)을 지키는것이 최우선 목표이다. NoSQL이 데이터 정합성(Data Consistency)을 지키지 않는 것은 절대 아니다. 데이터 정합성(Data Consistency)을 지키지 않는 건 데이터베이스로서 가치가 없다.
이 둘의 가장 큰 차이점은 데이터의 중복을 어느 정도 허용할 것인가? 라고 생각된다. !NoSQL#데이터 중복(Data Redundancy)
NoSQL이 중복을 허용하는 이유
JOIN 연산의 배제
NoSQL은 수평적 확장을 위해 데이터를 여러 서버에 분산 저장합니다. 이때 여러 서버에 흩어진 데이터를 JOIN 하는 작업은 성능에 막대한 지장을 줍니다. 이를 피하기 위해 필요한 데이터를 한 곳에 모아(중복 저장) 한 번의 쿼리로 읽어오도록 설계합니다.
읽기 성능 극대화
사용자가 화면을 볼 때 필요한 모든 정보를 하나의 'Document'나 'Row'에 다 담아두면, 여러 테이블을 뒤질 필요 없이 즉시 응답할 수 있습니다.
데이터 중복으로 인한 기회비용
중복을 허용하면 얻는 것도 있지만, 반드시 대가를 치러야 합니다.
-
데이터 수정의 복잡성 (Update Anomaly): 사용자 이름이 바뀌면, 그 이름이 중복 저장된 수천 개의 게시글 데이터를 모두 업데이트해야 합니다. 이때 일부가 누락되면 데이터 정합성이 깨집니다.
-
저장 공간 증가: 동일한 데이터가 반복 저장되므로 저장 용량을 더 많이 차지합니다. 하지만 현대의 클라우드 인프라에서는 저장 비용보다 컴퓨팅 성능(속도) 비용이 더 중요하므로 대개 용납됩니다.
-
결과적 일관성 (Eventual Consistency): 모든 중복 데이터를 즉시 수정하는 것이 어렵기 때문에, "잠시 동안은 데이터가 다를 수 있지만 결국에는 같아진다"는 원칙을 따르게 됩니다.
RDBMS vs NoSQL: 언제 무엇을 쓸까?
어느 하나가 절대적으로 우월한 것이 아니라, 서비스의 성격에 맞춰 선택하거나 두 가지를 혼합해서 사용합니다.
RDBMS를 써야 할 때
-
데이터 구조가 명확하고 변경될 일이 적을 때
-
금융 시스템처럼 데이터 정합성(Data Consistency)과 [트랜잭션(Transaction)|트랜젝션]이 매우 중요할 때
-
복잡한 쿼리와 JOIN 연산이 자주 필요할 때
NoSQL을 써야 할 때
-
데이터 구조가 확정되지 않았거나 자주 변경될 때
-
빅데이터, 로그 관리, 실시간 메신저처럼 막대한 양의 데이터를 빠르게 처리해야 할 때
-
데이터 정합성(Data Consistency)보다는 서비스의 가용성(Availability)(항상 접속 가능함)이 더 중요할 때
NoSQL은 "데이터가 조금 틀려도 괜찮으니, 절대 죽지 않고 엄청나게 빠른 시스템"을 만들 때 씁니다. 반면 RDBMS는 "성능이 조금 답답하더라도, 데이터는 단 1원, 1글자도 틀리면 안 되는 시스템"에 씁니다.
[!warning] 그렇다고 해서 NoSQL이 데이터정합성이 안맞단건 절대 아님 실시간으로 정합성을 맞춰주느냐? (RDBMS), 순간적으로는 안맞을 수 있지만 결과적으론 정합성이 맞다 (NoSQL)