✏️ RDB와 NoSQL
💡 RDB와 NoSQL의 차이
관계형 데이터베이스(RDB)
데이터 구조: 테이블 형태로 데이터를 저장하며, 각 테이블은 레코드(행)와 속성(열)으로 구성됩니다. 테이블 간의 관계는 외래키(Foreign Key)를 사용하여 정의됩니다.데이터 스키마: 엄격한 스키마를 가집니다. 데이터의 구조와 타입을 미리 정의해야 하며, 데이터의 변경이 필요한 경우, 스키마 변경이 복잡할 수 있습니다.쿼리 언어: 대표적인 쿼리 언어로 SQL(Structured Query Language)을 사용합니다. SQL을 이용하여 데이터를 조회, 수정, 삭제할 수 있습니다.트랜잭션: ACID 원칙(원자성, 일관성, 고립성, 지속성)을 준수하여 데이터의 일관성과 무결성을 보장합니다.스케일링: 수평적 확장이 어려워서 대부분 수직적 확장을 사용합니다. 대용량 트래픽 처리에 어려움이 있을 수 있습니다.
NoSQL 데이터베이스(NoSQL)
데이터 구조: 다양한 형태의 데이터 모델을 사용합니다. key-value, document, graph 등의 다양한 데이터 모델이 있습니다.데이터 스키마: 유연한 스키마를 가지며, 필요한 속성을 동적으로 추가할 수 있습니다. 스키마 변경이 간단하며, 다양한 형태의 데이터를 수용할 수 있습니다.쿼리 언어: SQL 대신 데이터베이스마다 다양한 쿼리 언어를 사용합니다. 예를 들어, MongoDB는 자체 쿼리 언어를 사용합니다.트랜잭션: 몇몇 NoSQL 데이터베이스는 ACID원칙을 준수하거나, 비교적 느슨한 일관성 모델(Consistency Model)을 따릅니다. 그러나 모든 NoSQL 데이터베이스가 이를 보장하지는 않습니다.스케일링: 수평적 확장이 용이합니다. 대용량 데이터 처리와 분산 환경에서 유리한 성능을 보일 수 있습니다.
요약
관계형 데이터베이스는 정형화된 데이터와 복잡한 관계를 다루는 데 유리하며, 데이터 일관성과 무결성을 중요시하는 경우에 적합합니다. 반면 NoSQL 데이터베이스는 비정형 또는 반정형 데이터, 대용량 데이터 처리, 빠른 확장 등의 경우에 유용합니다. 따라서 데이터베이스 선택은 사용하는 데이터의 특성과 요구사항에 따라 결정되어야 합니다.
| RDB(SQL) | NoSQL | |
|---|---|---|
| 데이터 모델 | 테이블 | Document, Key-Value, Column-Family, Graph |
| 개발 목적 | 데이터 중복 방지 | 애자일 / 확장가능성 / 수정가능성 |
| 확장성 | 수직적 확장에 용이 | 수평적 확장에 용이 |
| 스키마 | 엄격한 데이터 구조 | 유연한 데이터 구조 |
| 트랜잭션 | ACID 트랜잭션을 지원 | CAP이론을 기반으로 함 |
| 장점 | 명확한 데이터 구조, 데이터 중복이 없어 update 용이 | 유연한 데이터 구조, 새로운 필드 추가가 자유로움, 수평적 확장(Scale out)용이 |
| 단점 | 시스템이 커지면 쿼리가 복잡함, 비용이 큰 수직적 확장에 적합함 | 데이터 중복 발생 가능으로 update시 모든 컬렉션 수정 필요, 명확한 데이터 구조를 보장하지 않음 |
| 예시 | Oracle, MySQL, PostgreSQL 등 | MongoDB, DynamoDB, CassandraDB 등 |
👍 NoSQL의 강점과 약점
강점
유연한 데이터 모델링이 가능합니다. 데이터의 구조를 동적으로 조정할 수 있기 때문에 수평적 확장에 용이하며, 빠른 읽기와 쓰기가 가능합니다.- 빅 데이터, 로그 데이터, 센서 데이터 등과 같은 대량의 데이터를 다루는 데 용이합니다. NoSQL은 분산 아키텍처를 강조해, 데이터를 여러 노드로 분산 저장하고 처리하기 때문입니다.
약점
- 대부분의 경우 데이터베이스의 일관성에 약합니다. 일관성을 가용성, 분할 용인, 속도와 맞바꾸었다고 볼 수 있습니다.
- 스키마가 정해져 있지 않아, 데이터에 대한 규격화가 되어있지 않습니다.
- 데이터가 여러 컬렉션(테이블)에 중복되어 있어서 데이터를 UPDATE하는 경우 모든 컬렉션에서 변경을 수행해야 하기 때문에 느리고 작업이 번거로울 수 있습니다.
- ACID 트랜잭션을 지원하지 않거나, 제한적으로 지원하기 때문에 데이터 일관성이나 트랜잭션 처리가 중요한 경우 주의가 필요합니다.
🧢 CAP 원칙
CAP 원칙이란
- CAP 원칙은 분산 컴퓨팅 환경에서의 DBMS의 성능과 안정성을 설명하는 개념으로,
일관성,가용성,분할 내성중 세 가지 요소를 모두 만족하는 시스템은 존재하지 않음을 증명한 정리입니다.일관성(Consistency): 모든 노드는 동일한 순간의 데이터를 볼 수 있도록 보장합니다. 즉, 한 노드에서 데이터가 변경되면 다른 모든 노드에서도 같은 데이터 변경이 반영되어야 합니다.가용성(Availability): 모든 요청에 대해 성공이나 실패에 대한 응답을 받도록 보장합니다. 시스템이 어떤 노드의 장애나 오류로 인해 작동하지 않더라도 다른 노드가 계속 서비스를 제공할 수 있어야 합니다.분할 내성(Partition Tolerance): 네트워크 분할 등으로 인해 노드 간의 통신이 실패하거나 지연되더라도 시스템이 지속될 수 있도록 보장합니다. 네트워크는 항상 신뢰할 수 없으므로 이는 많은 경우에 반드시 필요로 합니다.
조합 별 특징
CA: 분할 내성을 포기하고 일관성과 가용성을 확보합니다. 이는 전통적인 관계형 데이터베이스에 해당됩니다.CP: 가용성을 포기하고 일관성과 분할 내성을 확보합니다. 원자성 읽기와 쓰기 작업을 필요로 하는 비즈니스 로직 등 높은 일관성을 요구하는 상황에 적합합니다.AP: 일관성을 포기하고 가용성과 분할 내성을 선택합니다. 분산 시스템에서 빠른 응답과 안정성을 요구하는 상황에 적합합니다.
🤔 RDB가 NoSQL에 비해 부하가 많이 걸릴 수 있는 이유
RDB의 정규화된 스키마, ACID 트랜잭션, Scalability 등이 NoSQL에 비해 부하가 많이 걸릴 수 있는 요인입니다.
정규화된 스키마- RDB는 데이터 정규화를 통해 중복을 최소화하고 데이터의 일관성을 유지합니다. 하지만 이로 인해 데이터 조회 시, 여러 테이블을 조인해야 할 수 있는데, 이러한 조인 연산은 성능에 부하를 줄 수 있습니다.
ACID 트랜잭션- RDB는 트랜잭션을 지원하여 데이터의 일관성과 무결성을 보장합니다. 하지만 트랜잭션 처리에는 추가적인 오버헤드가 따르며, 동시에 여러 트랜잭션이 처리되는 상황에서 락(lock) 문제로 인해 성능 저하가 발생할 수 있습니다.
Scalability- RDB의 엄격한 스키마로 인해 수평적 확장이 어렵습니다. RDB에서는 일반적으로 여러 테이블이 한 서버에 존재하며, 이로 인해 해당 서버에 디스크 및 네트워크 I/O가 집중되면 데이터베이스에 부하를 발생시킬 수 있습니다.
🤫 둘 중 어떤 것을 선택해야 할까?
RDB 사용이 더 좋을 때
- 관계를 맺고 있는 데이터가 자주 변경되는 애플리케이션의 경우
- 사용자와 데이터에 있어서 변경될 여지가 없는 명확한 스키마가 중요한 경우
NoSQL 데이터베이스 사용이 더 좋을 때
- 정확한 데이터의 구조를 결정할 수 없거나 변경/확장될 수 있는 경우
- 읽기를 자주 하지만, 데이터 변경은 자주 없는 경우
- 데이터베이스를 수평으로 확장해야하는 경우(방대한 양의 데이터를 다뤄야 하는 경우)
🙏 본 개념의 정리에 대한 피드백과 질문은 환영입니다!
본 개념의 다른 정리 및 피드백, 인터뷰 주제의 순서는 테크 인터뷰 스터디 Repository에서 확인 가능합니다.
📚 REFERENCE
티스토리 - RDBMS의 한계와 NoSQL을 사용하는 이유 (3) NoSQL 장단점, 특징
깃허브 - <데이터베이스> 관계형 vs. NoSQL 언제 무엇을 써야할까?
깃허브 - SQL과 NOSQL의 차이
티스토리 - RDB와 NoSQL의 차이는?
데이터온에어 - 데이터실무
미디엄 - Differences Between SQL And NoSQL: Is NoSQL Faster Than SQL?
미디엄 - [Elastic Search] 기본 개념과 특징(장단점)
티스토리 - [시스템 디자인] CAP 이론 정리
Grow Exponentially