NoSQL의 등장 배경
인터넷이 널리 보급되면서 다양한 애플리케이션이 등장하게 되고 사용자 트래픽도 늘어나게 되면서 애플리케이션에는 새로운 요구사항이 등장하게 되었다.
이러한 트래픽을 처리하기 위해 애플리케이션은 높은 처리량(high-throughput)을 가지며 낮은 지연 시간(low-latency)의 특성이 요구되었다. 예를 들어 페이스북, 트위터, 구글과 같은 SNS 플랫폼에서는 수백만 명의 사용자가 동시에 접속하는 환경에서 실시간으로 데이터를 처리해야 했다. 이러한 대용량 데이터를 처리하기 위해, 기존 RDBMS에서 주로 사용하던 scale-up(수직적 확장) 접근방식에서는 하드웨어의 물리적 한계와 비용 문제가 발생하였다.
동시에 다양한 사용자들이 다양한 형태로 데이터를 발생시키며 비정형 데이터가 급증하게 되었다. 텍스트, 이미지, 동영상, 위치 정보 등 다양한 형태의 데이터는 SQL의 엄격한 테이블 구조에 맞추기 어려웠다. 또한 애자일 개발 방법론의 확산으로 빠른 개발 주기와 유연한 데이터 모델이 필요해졌다.
이러한 상황에서 RDBMS는 다음과 같은 과제가 있었다:
- 확장성(Scalability)의 한계: 관계형 데이터베이스는 수직적 확장이 주를 이루어 대규모 분산 시스템에 적합하지 않았다.
- 스키마 경직성: 미리 정의된 스키마는 빠르게 변화하는 비즈니스 요구사항에 신속하게 대응하기 어렵게 만들었다.
- 복잡한 조인 연산: 대규모 데이터셋에서의 조인 연산은 성능 저하를 가져왔다.
- ACID 트랜잭션의 부담: 완전한 ACID 준수는 분산 환경에서 높은 성능을 유지하기 어렵게 만들었다.
기존 SQL의 특징과 단점
RDBMS의 특징
스키마와 정규화 기존 SQL의 경우, 스키마 기반 구조를 사용하고 테이블에서 중복 데이터를 줄이면서 데이터베이스의 이상현상을 줄이기 위해 정규화를 진행해 테이블을 분리시키는 접근 방식을 사용한다. 이렇게 분리된 테이블에서 전체 데이터를 가져오기 위해서는 join 연산이 필요하다.
ACID 속성 또한 RDBMS에서는 데이터의 일관성을 유지하기 위해 ACID 속성을 지키기 위한 메커니즘을 사용하는데, 특히 Isolation을 보장하기 위해 Lock과 같은 접근 방식을 사용한다
이러한 특징들은 정형화되어있는 데이터를 일관적으로 관리하는데 장점이지만, 위에 언급한 “대규모 트래픽이 몰려오는 상황”에서는 몇 가지 한계점이 있다.
RDBMS의 한계점
스키마와 정규화 → join 오버헤드 Join 연산을 위해 여러 테이블에 접근하는 과정에서 디스크 I/O 작업이 증가한다. 이렇게 각 테이블의 데이터 페이지를 메모리로 로드하는 과정에서 디스크 병목이 발생한다.
ACID 속성 → Lock 매커니즘에 의한 성능 제한 여러 트랜잭션이 동일한 데이터에 접근할 때 Lock 경합이 발생할 수 있다. 특히나 인기 있는 레코드에 대한 접근이 많은 경우, 각 트랜잭션이 Lock 을 획득하기 위해 대기하게 되며 성능이 감소할 수 있다.
RDBMS와 마이크로서비스 아키텍처의 부조화 추가적으로 RDBMS의 경우 현대의 마이크로서비스 아키텍처 측면에서도 맞지 않는 부분이 있다. 마이크로서비스 아키텍처는 각 서비스가 독립적으로 개발, 배포, 확장될 수 있도록 설계되었다.
RDBMS의 경우, 기본적으로 단일 서버에서 scale-up(수직적 확장)을 이용한 접근법으로 확장된다. 즉, 더 많은 CPU, 메모리, 저장 공간을 갖춘 강력한 서버로 업그레이드하는 방식이다. 하지만 마이크로서비스 아키텍처의 경우, Single Point of Failure를 줄이고 각 서비스의 독립적인 확장성을 보장하는 것이 핵심이므로, 하나의 서버만 확장하는 scale-up보다는 여러 서버로 부하를 분산하는 scale-out(수평적 확장) 방식이 더 적합하다.
이러한 scale-out 접근 방식을 RDBMS에 적용하시려면 어떻게 해야할까? RDBMS는 근본적으로 scale-out이 어렵다는 단점이 있다. 예를 들어, 테이블을 여러 서버에 나누기 위해 사용하는 샤딩(sharding) 기법이 있다. 여기서 가장 자주 사용되는 해시 방법을 적용하더라도 shard key를 신중하게 선택하고 hash 함수를 정의해야 하는 복잡함이 존재한다. 또한 한번 설계된 sharding 방식은 데이터가 증가하면서 재조정(re-sharding)이 필요할 때 매우 복잡한 마이그레이션 작업을 요구한다.
이러한 한계점들로 인해, 대규모 분산 환경에서 확장성과 유연성이 중요한 현대 애플리케이션의 요구사항을 충족시키기 위해 NoSQL 데이터베이스가 대안으로 등장하게 되었다.
NoSQL의 특징
유연한 스키마
NoSQL은 RDBMS 와 달리 유연한 스키마 특성을 가진다. 예를 들어 기존 SQL 에서
CREATE TABLE student (
id INT PRIMARY KEY,
name VARCHAR(20)
)
으로 테이블이 정의되어 있다면 student 테이블에는 정의된 칼럼 대로만 데이터를 넣을 수 있다.
반면 NoSQL (mongoDB) 의 경우,
db.createCollection("student");
db.student.insertOne({
name: "gin"
});
db.student.insertOne({
name: "kin",
city: "Busan",
hobby: "swimming"
})
처럼 각 Document 가 서로 다른 필드 구조를 가질 수 있다.
이러한 유연한 스키마를 가진다는 특성은 NoSQL 을 통해 애플리케이션 레벨 뿐만 아니라 데이터 베이스 레벨에서 더 많은 작업을 빠르게 처리할 수 있다는 장점을 가진다. 예를 들어 Redis 의 경우, 랭킹 시스템, 타임라인 등은 RDBMS에서 어플리케이션 레벨에서 구현해야 했던 연산을 Redis의 자료구조로 보다 빠르게 처리할 수 있다.
데이터의 중복 허용
RDBMS 의 경우, 테이블을 정규화 하여 중복된 데이터를 피하는 전략을 사용한다. 하지만 정규화에 의해 join 연산이 늘어나면서 성능이 하락하는 문제가 있었다. 반면 NoSQL의 경우, 정규화가 없으므로 중복을 허용함으로써 join 을 회피할 수 있다.
하지만 이러한 특성은 NoSQL 이 write 작업이 많은 곳에서는 적합하지 않음 을 나타낸다. 왜냐하면 데이터의 중복이 허용되면서, 하나의 데이터를 변경할 때 마다 모든 중복 위치를 찾아 일관되게 업데이트 해야하기 때문에 업데이트 비용이 증가하며, 여러 위치의 데이터를 업데이트 하지 못한다면 데이터가 불일치 할 수 있다.
CAP Theorem
CAP Theorem 은 데이터베이스가 Consistency, Availability, Partitioning 을 모두 만족할 수 없고, 둘만 만족할 수 있다는 뜻이다.
CAP
- Consistency : 모든 Client 가 언제나 같은 상태의 데이터를 바라볼 수 있다.
- Availability : 모든 Client 가 언제나 데이터에 접근할 수 있다.
- Partitioning : Database 가 물리적으로 전혀 다른 네트워크 공간에 위치할 수 있다. 네트워크 공간 사이가 단절되어도 시스템은 동작할 수 있다.
일반적으로 RDBMS 는 Consistency 와 Availability 를 만족하고, 이를 만족시키기 위해 ACID 속성을 가지고 있다. 하지만 NoSQL 은 분산 환경에 최적화 하기 위해 Partitioning 과 Consistency / Availability 를 만족하는 형태가 대부분이다. 따라서 NoSQL은 ACID 중 하나 이상을 만족하지 않으며 이렇게 분산환경에서 일부를 타협한 모델을 BASE (Basically Available, Soft state, Eventually Consistency) 라고 부른다.
NoSQL의 이러한 특성들은 그만큼 개발자가 애플리케이션에서 해당 데이터를 직접 관리해야 하는 책임을 증가시킨다.
RDBMS에서는 스키마, 정규화, 트랜잭션(ACID)과 같은 메커니즘이 데이터의 일관성과 무결성을 보장해주었다. 반면 NoSQL에서는 스키마가 유연하고 정규화 대신 중복을 허용하며, ACID 트랜잭션을 완전히 보장하지 않는 경우가 많다. 이로 인해 개발자는 다음과 같은 부분을 애플리케이션 단에서 직접 고려해야 한다:
- 데이터 모델링 시 중복된 데이터를 어느 수준까지 허용할지 결정
- 중복된 데이터의 변경 시, 일관성을 유지하기 위한 수동 업데이트 로직 필요
- 데이터 간 관계를 애플리케이션 단에서 관리해야 하므로 복잡한 비즈니스 로직이 증가
이처럼 NoSQL은 데이터 무결성과 일관성 보장을 시스템이 대신해주는 대신, 개발자에게 더 많은 판단과 책임을 요구하는 구조이다.
따라서 NoSQL은 읽기 작업이 많고, 자주 변경되지 않는 대규모 데이터를 빠르게 처리해야 하는 환경에서 유리하다. 예를 들어,
- SNS 타임라인, 로그 데이터, 사용자 행동 로그, 추천 시스템, 캐시 시스템 등과 같이
- 데이터가 대량으로 저장되고, 대부분 읽기 위주로 접근되며, 실시간 응답 속도가 중요한 서비스
에서는 NoSQL이 매우 적합하다. 반면, 복잡한 트랜잭션과 데이터 정합성이 핵심인 금융, 회계, 주문 처리 시스템 등에서는 여전히 RDBMS가 선호된다.