NoSQL의 쓰기 성능이 좋은 이유를 뭐라고 설명해야할까?

면접 질문에서 나온 ‘NoSQL이 왜 쓰기 작업에 뛰어난 성능을 내는가요?’에서 답변을 만족스럽지 못하게 한게 찜찜했다.

 

좀 더 잘 말할 수 있지 않았을까?

 

 

 

1. 수직적 확장(Scale-Up)보다 수평적 확장(Scale-out)에 최적화된 아키텍처

대부분의 NoSQL은 분산 클러스터를 기반으로 설계되어서 쓰기 작업을 여러 노드에 분산시킬 수 있다.

반면, RDB는 보통 단일 서버에 의존하는 경우가 많아서 쓰기 작업에 대해 확장성이 제한된다.

1. 스키마리스(Schema-less) 구조

RDB같은 경우는 정형화된 스키마를 가지기 때문에 미리 테이블 구조를 정의한다.

당연히 쓰기 작업시에도 스키마 검증을 거치면서 오버헤드가 발생한다.

반면 NoSQL은 스키마가 존재하지 않기 때문에 필드값 변경에 제약이 없어 자유로운 쓰기 작업이 가능하다.

1. 트랜잭션 부담의 차이

RDB는 흔히 알고 있는 ACID 원칙(원자성, 일관성, 고립성, 지속성)을 보장하기 위해 쓰기 연산시 많은 비용이 발생한다.

NoSQL은 보통 BASE(Basically Available, Soft state, Eventually consistent) 모델을 채택한다.

BASE 모델을 통해 데이터 일관성을 즉시 보장하지 않는 대신, 빠른 쓰기 속도를 제공한다.

 

 

나는 당장 생각나는게 NoSQL의 특징으로 ‘정형화되지 않은 스키마’라는 부분이었다.

 

스키마-리스 구조에 대한 부분을 설명하고 RDB에서 발생하는 오버헤드가 없어서 쓰기 성능이 좋다고 말했다.

 

근데 사실 면접관이 원하는 내용은 SQL문을 사용하는 RDBMS쪽과의 일관성 정책 차이가 아니였을까.

 

 

SQL이란?

절차적 질의 언어(Structed Query Language)의 줄임말

관계형 데이터베이스에 정보를 저장하고 처리하기 위한 언어

1. 명확히 정해진 데이터 구조(Schema)를 따라야한다.
2. 데이터의 중복을 피하기 위해서 관계(Relational)를 사용한다.

하나의 테이블에서 중복 없이 하나의 데이터만 관리하기 때문에, 일관성을 유지할 수 있다.

 

 

NoSQL이란?

Not Only SQL (Non-Relational Operational Database SQL)

 

기존 RDBMS가 갖던 특성 뿐만 아니라 다른 특성들을 부가적으로 지원한다.

보통 분산 시스템으로 동작하여 수평적 확장에 용이하고 확장성이 좋다.

 

보통 NoSQL은 관계를 맺는 컬렉션에 대해서 모두 수정해야하기 때문에 데이터를 자주 변경하는 경우 비효율적이다.

 

SQL은 스키마를 따르지 않으면 저장할 수 없지만, NoSQL은 다른 구조의 데이터를 같은 컬렉션에 저장할 수 있다.

 

RDBMS와 달리, 트랜잭션을 지원하지 않거나 제한적인 편이다. 당연히 ACID 원칙도 따르지 않는다.

 

 

 

분산 컴퓨팅의 CAP 이론

 

보통 CAP 이론을 기반으로 높은 확장성, 가용성을 우선시하며 일관성(consistency)을 최종적으로 보장하는 Eventual Consistency 방식을 채택한다.

 

기존 ACID 모델의 대안으로 나온 BASE 모델은 주로 NoSQL 데이터베이스에서 사용된다.

 

데이터베이스가 높은 확장성과 가용성을 갖도록 해서 데이터의 일관성에 대한 보장을 어느정도 완화한 개념이다.

 

 

BASE 모델 (Basically Available, Soft state, Eventually consistent)

핵심 요소는 3개인데 왜 BA/S/E로 나눠서 base라고 부르는지 의문이다.

 

일관성(consistency)가 중요한 ACID 모델과 다르게, BASE 모델은 가용성(availability)를 더 중시한다.

 

 

1. Basically Available:
   
   • 일부 노드나 서버가 다운되더라도 전체 시스템은 여전히 사용 가능해야함
2. Soft State:
   
   • 데이터가 여러 서버에 분산되고, 지연이나 장애로 인해 데이터의 일관성이 일시적으로 깨질 수 있음
   • 시스템의 상태가 항상 일정하지 않고 변경될 수 있으며, 시간이 지나면서 결국 일관성을 갖추는 방향
   • 이로 인해 일부 일시적인 불일치를 허용한다 (RDB의 즉각적인 일관성과 차이)
3. Eventually Consistent:
   • 시스템이 일부 불일치를 겪을 수 있지만,  시간이 지나면 결국 일관성을 갖추게 된다는 원칙
   • 일정 시간이 지난 후(시스템이 정상 상태로 돌아오면)에는 모든 노드가 동일한 데이터를 갖게 된다
   • 즉시 일관성을 요구하지 않으며, 데이터가 다른 노드들 사이에서 동기화되기까지의 지연 허용

 

 

그럼 언제 사용해야 좋을까? (NoSQL, SQL)

SQL 데이터베이스

애플리케이션에서 관계를 맺는 데이터 변경이 잦은 경우 : NoSQL에서는 여러 컬렉션을 모두 수정해야 하기 때문에 비효율적이다.

변경될 여지가 없고, 명확한 스키마가 중요한 애플리케이션인 경우

 

 

NoSQL 데이터베이스

정확한 데이터 구조를 알 수 없거나, 변경/확장될 가능성이 큰 경우

읽기 작업이 자주 발생하지만, 데이터 변경은 적은 경우

막대한 양의 데이터를 다루면서 데이터베이스를 수평적으로 확장해야 하는 경우