RDBMS vs NoSQL

RDBMS (관계형 데이터베이스 관리 시스템)

• 정의
  데이터를 테이블 형태로 저장하고, 테이블 간의 관계를 정의한다.
  SQL(Structured Query Language)을 사용하여 데이터에 접근하고 조작한다.

• 특징

  • 스키마 기반
    데이터 구조가 고정되어 있으며, 1)스키마가 엄격하다.
  • 2)ACID 속성
    원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)을 보장한다.
  • 정규화
    데이터 중복을 최소화 하기 위해 정규화 과정을 거칠 수 있다.

• 예시
  MySQL, PostgreSQL, Oracle Database 등

추가 궁금증

'스키마가 엄격하다'란?

데이터베이스에서 데이터의 구조와 형식이 명확하게 정의되어 있으며, 이 정의에 따라 데이터가 저장되고 관리되어야 한다는 의미

• 스키마(Schema)
  데이터베이스에서 테이블, 열, 데이터 타입, 제약 조건 등 데이터 구조에 대한 정의를 포함하는 구조.
  데이터베이스의 설계도 역할을 하며, 데이터가 어떻게 저장되고 상호작용하는지 규명함.

• 스키마의 특징

  1. 고정된 데이터 구조
     테이블의 각 열은 사전에 정의된 데이터 타입(정수, 문자열, 날짜 등)을 가져야 하며, 데이터베이스에 삽입되는 모든 데이터는 이 구조를 따라야 함.
     🔍예시) 사용자테이블이 이름, 이메일, 가입일, vip유무 등의 열로 구성되어 있다면, 각 열이 데이터 타입과 제약 조건이 명확하게 정의되어 있어야 함.
  2. 데이터 무결정 유지
     스키마가 가지는 엄격한 규칙으로 무결성을 보장하는 데에 유리함.
     🔍예시) 이메일 열이 반드시 이메일 형식이어야 한다거나, 가입일 에 Null 값이 들어올 수 없다는 등의 제약 조건을 설정할 수 있음.
     ⚡ 이런 제약 조건은 잘못된 데이터가 입력되는 것을 방지하여 데이터의 일관성을 유지
  3. 변경의 어려움
     스키마가 고정되어 있으므로 데이터 구조를 변경하려면 데이터베이스에 대한 추가 작업이 필요
     🔍예시) 이미 정의된 스키마로 운영 중인 데이터베이스에 새로운 열을 추가하거나 기존 열의 데이터 타입을 변경하려면 테이블을 수정해야 함. 이 과정에서 기존 데이터의 손실이나 일관성 문제가 발생할 수 있음. → 유연성이 떨어짐.
  4. 쿼리 최적화
     데이터 구조가 명확히 정의되어 있으므로 쿼리 최적화가 용이함.
     데이터베이스 엔진은 스키마 정보를 바탕으로 쿼리를 최적화하고 인덱스를 생성하여 성능을 향상시킬 수 있음.

• 스키마의 장단점

  • 장점
    데이터 무결성 보장
    쿼리 성능 최적화
    명확한 데이터 구조로 인한 빠른 이해(이해 용이성)

  • 단점
    유연성이 떨어짐
    초기 설계시 많은 투자 필요(신중하게 설계 해야 함)

'ACID'란?

• 원자성(Atomicity)

  • 정의
    트랜잭션 내의 모든 작업이 성공적으로 수행되거나, 하나라도 실패하면 모든 작업이 롤백되어 이전 상태로 되돌아 가는 성질. 모 아니면 도
  • 🔍대표 예시
    돈이 A 계좌에서 B 계좌로 이동하는 단계가 있다. 만약 B 계좌에 돈이 성공적으로 입금되었지만 A 계좌에서 돈이 차감되지 않았다는 가정을 해보자. 그럼, B 계좌에는 돈이 들어와서 잔고의 금액이 늘었다라는 작업이 성공적으로 마쳤지만, A 계좌에는 돈이 나가서 잔고의 금액이 줄었다라는 작업은 실패했다고 할 수 있다. 이런 경우, 모두 실패로 간주하여 작업을 하기 전 상황으로 되돌려야 한다.

• 일관성(Consistency)

  • 정의
    트랜잭션이 시작되기 전과 후의 모든 규칙과 제약 조건이 만족해야 한다.
  • 🔍대표 예시
    은행 계좌의 잔액이 항상 0원 이상이어야 한다는 규칙이 있을 때, 돈 이체 트랜잭션이 완료된 후에도 이 규칙이 유지되어야 한다. 즉, 트랜잭션이 완료된 후에도 잔액은 0원 미만이 되면 안된다.

• 고립성(독립성)(Isolation)

  • 정의
    한 트랜잭션이 진행 중일 때 다른 트랜잭션이 그 트랜잭션의 중간 결과를 볼 수 없도록 함. 이를 통해 트랜잭션의 실행 순서에 관계없이 결과가 일관되게 유지됨.
  • 🔍대표 예시
    트랜잭션은 병행처리(특정 시간 동안 작업을 하다가 부여된 시간이 끝나면 다른 트랜잭션을 실행하해 나가는 방식)를 할 수 있음. 이 때, 많은 트랜잭션들이 병행되어 조금씩 처리되어 가는도중 공통된 데이터를 조작하는 경우, 데이터가 일명 '꼬이는' 상황이 발생함.
    A 트랜잭션에서 은행 계좌에 100원을 빼내는 연산을 하던 도중, B 트랜잭션으로 처리 순서가 넘어가면서 50원이 빼내는 연산이 먼저 처리되는 경우.
    고립성(독립성)을 보장하면, 이러한 이체 작업 중 다른 트랜잭션이 접근하더라도 동일한 계좌를 동시에 수행할 수 없게 함.

• 지속성(Durability)

  • 정의
    성공적으로 마친 트랜잭션은 영구적으로 저장되어야 하며, 이후 시스템 장애가 발생하더라도 손실되지 않아야 함.
  • 🔍대표 예시
    이체 작업을 완료한 후 시스템 오류가 발생하더라도, 이체된 금액은 데이터베이스에 저장되어 있어야 하며, 시스템 복구 후에도 결과는 유지되어 있어야 함.

NoSQL

• 정의
  다양한 데이터 저장 방식(문서, 키-값, 열 기반 등)을 지원하며, 관계형 데이터베이스의 제약을 덜 받음.

• 특징

  • 유연한 스키마
    스키마가 없거나 느슨하게 정의되어 있어 데이터 구조의 변화를 쉽게 수용.
  • 1)수평적 확장성(Scale-Out)
    데이터가 증가하더라도 서버를 추가하여 쉽게 확장할 수 있음.

• 예시
  MongoDB, Cassandra, Redis 등

추가 궁금증

'수평적 확장성'이란?

데이터베이스를 관리하는 서버의 성능을 올리는 수직적 확장성(Scale-Up)과 달리,
데이터베이스를 분산하여 접근을 분산하는 방식

• 🔍 예시

  RDB의 수평 확장
  
  데이터베이스에 들어간 데이터를 분리하기 위해 사용자 테이블의 1~2를 관리하는 서버(이하 A)와 3~4를 관리하는 서버(이하 B)로 분할했다고 가정하자.
  이후, 테이블을 늘리며 영상이라는 테이블과 두 테이블을 논리적으로 이어주는 관계 테이블을 추가했다고 하자.
  또한, 데이터의 양이 많아져 새로운 서버(이하 C)가 추가되었다면, 데이터를 조회할 때 매우 복잡해진다.

  예를 들어, 운이 좋게 서버 A에 1번 사용자 정보와 이와 관련된 영상 및 관계 정보가 있다면 다행이다. 하지만, 1번 사용자가 A 서버에 영상은 C 서버에 그 관계는 B 서버에 관리 중이라면, 데이터 추출이 매우 복잡해 진다.
  이는 RDB 특성상 테이블 간의 관계는 더욱 복잡해 질 수 있으며, 결과적으로 수평 확장을 하기 전 매우 구체적인 설계가 요구된다.

  NoSQL의 수평 확장
  
  이처럼 관리하는 NoSQL이 있다고 가정해 보자.
  이런 형태의 데이터가 100만개 였을 당시 A 서버로 관리하다가 점차 많아지면서 B, C 서버를 추가하여 각각 100만개 씩 관리하고 있다고 가정해 보자.
  데이터가 많아지거나 복잡해 지더라도 데이터 추출에는 전혀 영향을 주지 않는다. 왜냐하면, 사용자 데이터 안에 사용자와 관련된 영상 정보 등이 다 포함되어 있기 때문이다.

이처럼 데이터의 범주를 분할하여 다른 서버(디바이스)로 관리하는 것을 수평적 확장이라고 하며, 여러 테이블의 관계를 관리하는 RDBMS보다 NoSQL이 수평적 확장에 더욱 유리하다.