SQL과 NoSQL

1. SQL과 NoSQL 구조

관계형 데이터베이스 (RDBMS):

• RDBMS는 데이터를 테이블 형태로 저장하며, 정해진 스키마(schema)에 따라 제약을 준수함
  • 테이블 내에서 정합성을 유지하기 위해 데이터 구조(예: 데이터 타입, 열의 개수)를 반드시 충족해야 함.
  • 테이블 간에 정합성을 유지하기 위해서 외래키(Foreign Key)를 사용해서 관계(Relation)를 충족해야함
•  RDBMS는 데이터 중복을 줄이고 정합성을 유지하기 위해 데이터를 여러 테이블로 분리합니다(정규화).
• 테이블 간에 강력한 **참조 무결성(Referential Integrity)**을 보장해야 하므로, 특정 테이블에 대한 연산이 다른 테이블에 영향을 줄 수 있습니다.
• **ACID(Atomicity, Consistency, Isolation, Durability)**를 보장.
  • 데이터 일관성을 유지하는 데 강점.
  • 은행, 금융, 전자상거래 등 일관성과 정확성이 중요한 시스템에서 선호.

 

NoSQL:

• 데이터 모델에 따라 여러 종류로 나뉨 :
  1. 문서(Document) 모델: JSON, BSON 형태 (예: MongoDB)
  2. 키-값(Key-Value) 모델: Key와 Value 쌍으로 데이터 저장 (예: Redis)
  3. 열(Column-family) 모델: 데이터를 컬럼 기반으로 저장 (예: Cassandra, HBase)
  4. 그래프(Graph) 모델: 노드와 엣지로 데이터 관계 표현 (예: Neo4j)
•  스키마가 유연하거나 없는 경우가 많아, 테이블 내 혹은 테이블 간의 데이터 제약이 지켜지지 않음.
  
  • 데이터 간 관계를 최소화하고, 다른 노드와 연계하여 처리하는 대신 단일 노드에서 데이터를 처리하도록 설계되었습니다.
• BASE(Basically Available, Soft state, Eventually consistent) 모델을 따르는 경우가 많음.
  • 트랜잭션보다 가용성과 확장성을 우선.
  • 데이터는 **최종적 일관성(Eventual Consistency)**을 보장하며, 즉각적으로 모든 노드에 동기화되지 않아도 됩니다.
  • 실시간 분석, 소셜 네트워크 등 일부 데이터 불일치가 허용되는 시스템에서 적합.

 

2. 데이터 처리 속도

RDBMS:

• 복잡한 쿼리와 조인(Join) 처리가 가능.
  • 데이터를 정규화하여 중복을 제거하고, 효율적으로 관리. 하지만 대규모 데이터에서 복잡한 조인이 많을 경우 성능 저하 발생 가능.
• RDBMS에서 데이터를 삽입(INSERT)할 때 여러 번의 조회(SELECT) 동작이 발생
  • 외래 키(FK) 참조 무결성 검사 : 삽입하려는 데이터가 참조하는 부모 테이블의 값이 존재하는지 확인하기 위해 SELECT 조회가 발생.
  • UNIQUE 제약 조건 검사 : UNIQUE가 설정된 컬럼이 이미 존재하는 값을 가지는지 확인하기 위해 조회 발생.
  • 자동 증가(Auto Increment) 값 조회 : AUTO_INCREMENT  컬럼이 있는 경우, 현재 마지막 ID 값을 확인하기 위해 조회가 발생할 수 있음 

 

NoSQL:

• 데이터를 비정규화하여 저장. 조인 없이 데이터를 조회하므로 읽기 속도가 빠름.
  • 단순 쿼리에 최적화되어 있고, 대량의 데이터를 빠르게 처리 가능.
  • 복잡한 데이터 관계가 필요한 경우 추가 설계 필요.

 

전통적인 **관계형 데이터베이스 관리 시스템(RDBMS)**은 분산 데이터베이스와 같은 방식으로 데이터를 수평적으로 확장하는 것이 본질적으로 어렵습니다. RDBMS는 ACID(Atomicity, Consistency, Isolation, Durability) 특성을 유지하며 데이터의 일관성과 무결성을 보장하는 데 최적화되어 있는데, 이 특성 때문에 데이터베이스를 여러 노드에 분산하는 데 있어 몇 가지 중요한 제약이 있습니다.

 

 

3. 확장성

RDBMS:

• 주로 스케일업(Scale-up) 기반.
  • 더 많은 데이터를 처리하려면 기존 서버의 성능을 업그레이드해야 함(CPU, RAM, SSD 등).
  • 수직 확장이 한계에 도달하면 성능 병목 발생 가능.

NoSQL:

• 스케일아웃(Scale-out) 중심.
  • 새로운 서버를 추가하여 수평 확장이 가능.
  • 데이터가 자동으로 여러 노드에 분산되고, 트래픽도 나눠 처리하여 확장성이 뛰어남.
  • 빅데이터 처리와 대규모 트래픽에 적합.

 

 

4. RDBMS의 확장성 제약

1. 수직 확장(Vertical Scaling)에 의존:
   • 전통적으로 RDBMS는 하나의 강력한 서버에서 실행되도록 설계되었습니다. 따라서 더 많은 성능이 필요할 때는 서버의 하드웨어(예: CPU, 메모리, 디스크)를 업그레이드하는 수직 확장이 일반적입니다.
   • 수직 확장은 어느 정도까지는 유효하지만, 결국에는 하드웨어의 물리적 한계에 도달할 수 있고 비용이 매우 비싸집니다.
2. 수평 확장(Scale-Out)이 어려움:
   • 데이터 일관성 유지: RDBMS는 데이터의 일관성을 엄격하게 유지하기 위해 설계되었기 때문에, 데이터를 여러 서버에 분산할 경우 일관성을 유지하는 것이 매우 복잡해집니다. 특히 분산된 노드들 간에 트랜잭션을 처리할 때 ACID 특성을 유지하는 것은 큰 도전 과제입니다.
   • 복잡한 쿼리: RDBMS는 복잡한 조인, 집계, 트랜잭션을 효율적으로 처리하기 위해 설계되었습니다. 하지만 데이터가 여러 노드에 분산되면 이러한 쿼리의 성능이 저하될 수 있습니다. 예를 들어, 여러 노드에서 데이터를 수집하고 조합하는 데 시간이 오래 걸릴 수 있습니다.
   • 복제와 샤딩: 데이터를 여러 노드에 분산하는 일반적인 방법은 샤딩(sharding) 또는 **복제(replication)**입니다. 그러나 RDBMS에서 샤딩은 매우 복잡하고, 잘못된 샤드 키를 선택할 경우 데이터 불균형, 핫스팟 문제 등이 발생할 수 있습니다. 복제는 읽기 작업에서는 유용하지만, 쓰기 작업에서는 여전히 단일 노드가 병목이 될 수 있습니다.

RDBMS에서의 확장 가능성

최근 몇 년 동안, RDBMS가 수평 확장을 지원하기 위해 여러 개선이 이루어졌습니다. 하지만 여전히 전통적인 NoSQL 또는 NewSQL 시스템과 비교했을 때 확장성이 제한적입니다.

1. 분산 SQL 데이터베이스: 일부 현대적인 RDBMS는 분산 환경에서 SQL과 ACID 특성을 유지하기 위해 분산 SQL 접근 방식을 도입했습니다.  여러 노드에 걸쳐 데이터를 분산하고도 SQL 쿼리와 트랜잭션을 지원합니다.
2. 샤딩(Sharding) 지원:
   1. 일부 RDBMS(예: MySQL의 InnoDB Cluster, PostgreSQL의 Citus)는 샤딩 기능을 지원하여 데이터를 수평적으로 분산할 수 있게 합니다. 그러나 이러한 기능을 제대로 활용하려면 상당한 구성 및 관리가 필요하며, 애플리케이션 수준에서 샤딩 논리를 구현해야 할 수도 있습니다.
3. 읽기 확장성(Read Scalability):
   • 복제(replication): RDBMS는 여러 복제본을 만들어 읽기 작업을 분산할 수 있습니다. 이를 통해 읽기 성능을 개선할 수 있지만, 쓰기 작업은 여전히 주 노드(Primary Node)에서만 처리되므로 이 부분이 병목이 될 수 있습니다.

결론

전통적인 RDBMS는 그 설계 특성상 분산 데이터베이스처럼 쉽게 수평 확장이 되지 않습니다. 특히, 데이터 일관성과 복잡한 쿼리를 처리하는 능력 때문에 데이터를 여러 노드에 걸쳐 분산하는 것이 어렵습니다.

그러나 현대의 일부 RDBMS는 제한적이지만 수평 확장을 지원하기 위한 기능을 제공하며, 분산 SQL 데이터베이스와 같은 새로운 기술들은 이러한 문제를 해결하기 위한 노력의 일환으로 개발되고 있습니다. 따라서 RDBMS의 확장성을 고려할 때, 애플리케이션의 요구사항에 따라 수직 확장과 수평 확장 중 어떤 접근이 적절한지 평가해야 합니다.