NoSQL에 대해 정리하기에 앞서, 이것이 왜 등장하였는지를 먼저 정리해보았다.
데이터를 관리하기 위해서 오랜 기간 사용되어왔던 표준 방식은 RDB를 사용하는 방식이었다. RDB는 관계형 데이터베이스로, 정형화된 데이터와 트랜잭션의 ACID를 보장하여 금융 시스템과 같이 데이터의 일관성이 중요한 분야에서 활발하게 이용되고 있다.
하지만 시간이 흐르면서 서비스를 이용하는 사용자는 많아지고 데이터의 형태는 다양해지면서 RDB는 몇 가지 한계에 부딪혔다.
RDB의 한계
1. 유연하지 않은 스키마
RDB는 데이터를 저장하기 전에 테이블의 스키마를 미리 정의해야 한다. 예로, 쇼핑몰에 "로켓배송" 기능을 추가하려면 기존 주문 테이블에 로켓배송과 관련된 새로운 컬럼을 추가해야 한다. 이처럼 새로운 기능이 생길 때마다 지속적으로 스키마를 변경해야 한다는 단점이 있다.
2. 확장성의 부족
대용량의 데이터가 실시간으로 발생하는 환경에서 RDB는 Write 작업에 부하가 걸릴 수 있다. 이 문제를 해결하기 위해 Scale Up(하드웨어 성능 향상)을 시도하지만, 이는 비용이 많이 들고 한계가 있다. RDB는 데이터가 강하게 스키마로 묶여 있고 조인을 많이 사용하기 때문에 데이터를 여러 서버로 Sharding(분산)하기 어렵다. 이런 구조적 단점으로 Scale Out을 적용하기 어렵다.
3. 조인(JOIN)으로 인한 성능 저하
RDB는 데이터의 중복을 피하기 위해 정규화를 진행한다. 이 덕분에 데이터의 일관성을 유지할 수 있지만, 여러 테이블에 흩어진 데이터를 다시 합치기 위해 JOIN연산이 빈번히 발생한다. JOIN이 많이질수록 Read 성능이 저하되고 DB 서버에 부하가 가중된다.
NoSQL의 등장
2000년대 후반, 폭발적으로 증가하는 대규모 데이터, 높은 처리량, 낮은 응답 시간에 대한 요구가 커지면서 새로운 형태의 데이터베이스인 NoSQL이 등장했다. 특히 비정형 데이터의 증가가 NoSQL의 확산을 가속화하였다.
비정형 데이터는 미리 정해진 구조가 없는 모든 데이터를 의미한다. 사진, 영상, 음성 파일 등은 RDB의 테이블 구조에 저장하기가 매우 까다롭다. NoSQL은 이러한 데이터에 최적화된 유연성을 제공한다.
NoSQL의 특징
1. 유연한 스키마
NoSQL은 스키마를 미리 정의할 필요가 없다. 예를 들어, MongoDB는 JSON과 유사한 document 형태로 데이터를 저장한다. 새로운 데이터를 추가할 때 원하는 컬럼을 자유롭게 추가할 수 있어, 변화에 빠르게 대응할 수 있다.
- RDB 예시
-- 컬럼을 미리 정의해야 함
CREATE TABLE products (
id INT PRIMARY KEY,
name VARCHAR(255),
price DECIMAL(10, 2)
);
-- 컬럼 추가 시 ALTER TABLE 필요
ALTER TABLE products ADD COLUMN brand VARCHAR(255);- NoSQL 예시
// 스키마 정의 없이 데이터 삽입 가능
db.products.insertOne({
name: "노트북",
price: 1500000
});
// 다음 데이터에는 새로운 필드(컬럼)를 추가해도 됨
db.products.insertOne({
name: "스마트폰",
price: 900000,
brand: "SAMSUNG"
});2. JOIN 회피를 위한 중복 허용
NoSQL은 데이터 중복을 허용하는 대신 JOIN 연산을 피한다. 예를 들어, orders 컬렉션에 사용자의 이름과 전화번호를 직접 저장하기 때문에, 주문 내역을 조회할 때 별도의 users 컬렉션을 참조할 필요가 없다.
// RDB에서 JOIN이 필요했던 데이터를 하나의 문서에 저장
db.orders.insertOne({
_id: 123,
order_date: "2023-10-27",
product_name: "무선 키보드",
username: "김철수",
phone_number: "010-1234-5678"
});다만, 데이터가 중복되기 때문에 사용자의 전화번호 등이 변경되면 관련 데이터를 모두 업데이트 해야하기 때문에 application 레벨에서 스키마 관리가 필요하다.
3. Scale Out에 최적화
NoSQL은 여러 대의 서버에 데이터를 분산하여 저장하는 Scale Out에 유리하게 설계되었다. 데이터를 여러 서버에 나누어 저장하고 처리하므로, 대규모 트래픽을 효율적으로 분산하고 안정적으로 처리할 수 있다.
4. ACID 대신 BASE를 추구
NoSQL은 ACID를 일부 포기하고, BASE(Basically Available, Soft state, Eventually consistent)를 추구한다. 즉, 데이터의 일관성보다는 높은 처리량과 낮은 응답 시간을 중시한다. 이 덕분에 대규모 서비스에 적합하지만, 금융이나 예약 시스템처럼 데이터의 일관성이 절대적으로 중요한 환경에서는 사용에 주의가 필요할 것이다.
마무리
RDB는 여전히 금융, 결제, 예약 시스템처럼 데이터의 정확성과 무결성이 최우선인 환경에서 핵심적인 기술이다. 반면, NoSQL은 대규모 사용자 트래픽, 비정형 데이터 저장, 빠른 응답 속도가 중요한 환경에서 강력한 성능을 보여준다.
즉, NoSQL은 RDB를 완전히 대체하기 위한 기술이 아니라, 데이터 특성과 서비스 요구사항에 따라 선택할 수 있는 또 하나의 도구라고 표현하는 것이 맞는 것 같다. 실제로 많은 기업들은 RDB와 NoSQL을 혼합하여 사용하며, 각각의 장점이 필요한 곳에 적절히 배치하는 전략을 취하고 있다.
결론적으로, RDB의 안정성과 NoSQL의 확장성을 이해하고, 상황에 맞게 선택하는 것이 현대 서비스 아키텍처에서 가장 합리적인 접근이다.
