요즘은 전통적인 관계형 데이터베이스에 NoSQL을 혼용해서 사용하는 경우가 많습니다.
이렇게 두 가지를 혼용해서 사용하는 이유는 각각의 장점이 다르기 때문에 다양한 요구사항에 맞춰 최적화된 성능을 제공하기 위해서인데요.
RDB(Relation Database)와 NoSQL의 차이를 알아야 어떤 부분에서로 서로 간의 시너지가 날 수 있는지 이해할 수 있습니다.
이 2가지 DB의 차이는 근본적으로 취급하는 데이터 구조에 의해서 발생한다고 할 수 있는데요.
RDB는 정형 데이터(Structured Data)에 강합니다. 테이블 간 관계를 바탕으로 데이터를 저장하고, 트랜잭션을 안전하게 관리하며, SQL을 통해 복잡한 쿼리를 수행할 수 있습니다. 특히나 데이터를 정확하고 일관되게 관리해야 할 때 RDB가 적합합니다.
그에 반해, NoSQL은 비정형 데이터(Unstructured Data) 또는 반정형 데이터(Semi-Structured Data)에 적합합니다. NoSQL은 여러 종류가 있는데 문서, 키-값, 그래프, 컬럼 기반이 있으며, 스키마가 유연하거나 데이터 구조가 자주 변경될 때 유리합니다. 대규모 데이터를 빠르게 처리하고, 수평 확장성이 뛰어나기 때문에 트래픽이 많은 환경에서 성능을 최적화하는데 효과적입니다.
데이터 유형 | 특징 | 예시 | |
RDB | 정형 데이터 | 고정된 스키마, RDBMS 사용, 데이터가 일관성 있음 | SQL 데이터베이스, 엑셀 스프레드시트 |
NoSQL | 비정형 데이터 | 고정된 구조 없음, 다양한 형식의 데이터 포함 | 텍스트 문서, 이미지, 오디오, 비디오, 소셜 미디어 콘텐츠 |
반정형 데이터 | 구조가 일부 있지만 완전하지 않음, 태그와 키-값 쌍 포함 | JSON, XML, 웹 로그, API 응답 |
이러한 데이터 구조의 차이점으로 인해 아래의 차이점이 발생하게 됩니다.
1. 확장성 요구
RDB는 주로 수직 확장성에 기반합니다. 즉, DB 서버를 더 좋은 하드웨어로 바꾸는 방식으로 확장을 해야 하는 것입니다. 그러나 그것은 한계가 있기 때문에 데이터가 폭발적으로 증가하거나 트래픽이 높아질 때 확장성에 제약이 있을 수 있습니다.
NoSQL은 수평 확장성이 뛰어나서, 서버를 추가하여 대량의 데이터를 분산해 저장하기가 수월합니다. 특히 분산 시스템에 적합하기 때문에 고가용성과 대용량 처리에 강점이 있습니다.
따라서 대규모 애플리케이션의 경우 NoSQL로 확장성이 필요한 데이터를 관리하면서, 핵심적인 데이터는 RDB에 저장합니다.
2. 트랜잭션 및 일관성 요구
RDB는 ACID (Atomicity, Consistency, Isolation, Durability) 특성을 충족하는 트랜잭션 관리에 매우 강합니다. 이 말은 데이터의 일관성 및 무결성이 엄격하게 유지되어야 하는 핵심적인 데이터, 예를 들어 유저 데이터, 결제 데이터 등에 적합하다는 의미입니다.
NoSQL는 CAP (Consistency, Availability, Partition tolerance) 이론에서 주로 가용성(Availability)과 분할 허용성(Partition tolerance)에 초점을 맞춰서 분산된 데이터 처리에 이점을 가지고 있습니다.
3. 특정 데이터 처리 방식 최적화
RDB는 테이블 간의 관계가 중요하거나 복잡한 Join 작업이 필요할 때 적합합니다. 데이터가 잘 구조화되어 있어야 하며, 이를 통해 강력한 쿼리 기능을 제공합니다.
NoSQL은 키-값 조회나 문서 저장 등 특정 데이터 처리 방식에 매우 빠릅니다. 예를 들어, 사용자 프로필 정보나 캐시 데이터를 키-값 구조로 저장하면 빠른 읽기/쓰기 성능을 얻을 수 있습니다.
정리하자면
RDB의 장단점
[장점]
1. 데이터 무결성: 테이블 간의 관계를 명확하게 설정할 수 있어 데이터 무결성이 보장됩니다. 예를 들어, 사용자 계정, 게임 스코어, 구매 내역 등 핵심적인 데이터를 철저하게 관리할 수 있습니다,
2. 복잡한 쿼리 가능: SQL을 사용하여 다차원적인 질의를 할 수 있습니다.
3. ACID 트랜잭션 보장: 금융 거래나 중요한 데이터 변경 작업에서 일관성을 유지할 수 있습니다. 예를 들어, 어떠한 결제가 이뤄질 때, 결제가 완료되지 않으면 해당 상품이 지급되지 않는 것이 보장됩니다.
[단점]
1. 확장성의 한계: 수직 확장에 의존하기 때문에, 트래픽이 많아질수록 성능 문제가 발생할 수 있습니다. 서버 성능을 높이는데 결국은 한계가 있습니다.
2. 복잡한 스키마 변경 어려움: 스키마가 고정되어 있기 때문에, 새로운 기능 추가 시 데이터베이스 구조를 변경하는 것이 복잡하고 어렵습니다.
NoSQL의 장단점
[장점]
1. 확장성: 수평 확장이 쉬워, 여러 서버에 데이터를 분산 저장하여 큰 트래픽을 감당할 수 있습니다. 대규모 온라인 게임에서 전 세계 유저의 데이터를 빠르게 처리할 수 있습니다.
2. 유연한 스키마: 스키마가 고정되어 있지 않아, 데이터 구조가 자주 변경되는 경우에 유리합니다. 예를 들어, 게임에서 새로운 캐릭터 특성이나 기능이 추가될 때, 기존 스키마를 변경하지 않고도 바로 적용이 가능합니다.
3. 빠른 읽기/쓰기: 데이터를 빠르게 읽고 쓸 수 있어, 실시간 로그 처리나 캐시로 적합합니다. 예를 들어, 게임 내 실시간 랭킹이나 채팅 메시지 처리에 적합합니다.
[단점]
1. 데이터 일관성 문제: 데이터 일관성보다는 가용성에 집중하기 때문에, 잘못된 데이터를 저장할 가능성이 있습니다. 트랜잭션이 보장되지 않아서 아이템이나 상품을 중복 지급할 가능성이 있습니다.
2. 복잡한 질의 제한: RDB처럼 복잡한 Join 쿼리나 연산을 지원하지 않기 때문에, 여러 데이터를 동시에 조회해야 하는 상황에서는 비효율적일 수 있습니다.
이제 위에서 알아본 내용을 기반으로 RDB와 NoSQL을 혼용한 온라인 게임 웹페이지 예시를 들어보겠습니다.
RDB를 사용하는 부분
1. 사용자 정보 및 게임 데이터 관리: 사용자 계정, 아이템 소유 정보, 게임 내 레벨, 캐릭터 상태 등은 RDB에 저장합니다. 이 데이터들은 관계가 매우 중요하고, 수정 시 트랜잭션이 보장되어야 하기 때문입니다.
- ex) 사용자가 게임 내 아이템을 구매할 때, 해당 아이템이 사용자 계정에 정상적으로 추가되고 결제가 성공적으로 완료되었는지 확인하기 위해 ACID 트랜잭션이 필요합니다.
2. 결제 시스템 관리: 게임 내 상점에서의 결제 내역을 관리할 때는 RDB에 저장하는 것이 적절합니다. 구매 이력이나 결제 정보는 무결성이 굉장히 중요하기 때문입니다.
- ex) 사용자가 결제 시도 후 페이지를 새로 고침해도 결제가 두 번 이루어지지 않도록 RDB가 안전하게 데이터를 처리합니다.
NoSQL을 사용하는 부분
1. 캐싱 및 실시간 데이터: NoSQL을 캐시 레이어로 사용하여 빠른 접근이 필요한 데이터를 저장합니다. 실시간 랭킹이나 게임 내 채팅 데이터는 NoSQL에 저장하여 읽기/쓰기 성능을 극대화할 수 있습니다.
- ex) 매 게임에서 사용자 랭킹이 갱신될 때마다 RDB에 계속 저장하게 되면 성능이 떨어질 수 있습니다. 대신 NoSQL에 랭킹 데이터를 캐싱해주고, 일정 시간마다 또는 랭킹이 변경될 때만 RDB에 동기화한다면 성능을 최적화할 수 있습니다.
2. 로그 데이터 저장: 게임 내 이벤트나 사용자 행동 기록(로그)은 NoSQL에 저장하는 것이 적절합니다. 대규모 트래픽에서 발생하는 로그 데이터를 실시간으로 처리하고 분석하는데 NoSQL이 매우 유용하기 때문입니다.
- ex) 사용자의 행동 로그를 NoSQL에 저장하고, 나중에 이를 분석해 사용자 활동을 파악하고 개선할 점을 찾을 수 있습니다.
좀 더 구체적으로 예시를 들어보자면
- 회원가입/로그인: 회원가입 및 첫 로그인할 때는 RDB를 사용하고 그 이후 세션 or 토큰 검증 시에는 NoSQL 사용
- 실시간 게임 이벤트: NoSQL에 실시간 이벤트 데이터(랭킹, 채팅)를 저장해 빠르게 처리하고, 중요한 데이터는 RDB에 주기적으로 동기화
- 결제 처리: 사용자가 결제한 내역은 RDB에 저장해 무결성을 보장하고, 결제와 관련된 실시간 알림 또는 이벤트는 NoSQL을 통해 처리
- 대시보드/관리 툴: 관리자용 도구는 RDB에서 제공하는 데이터를 기반으로 정확한 통계를 확인하고, 대용량의 사용자 활동 로그 분석은 NoSQL로 빠르게 조회하고 분석
이런 식으로, RDB와 NoSQL을 혼용하여 핵심적인 데이터의 무결성을 유지하면서도 자주 조회되고 실시간성이 필요한 데이터는 NoSQL을 통해 성능을 최적화할 수 있습니다.
'방구석 컴퓨터 > 방구석 DB' 카테고리의 다른 글
PK(Primary Key)와 UK(Unique Key) (0) | 2024.11.27 |
---|---|
데이터베이스 인덱싱 (1) | 2024.11.20 |
JPA와 프로시저 (1) | 2024.11.13 |
NoSQL과 스프링부트 캐싱 (0) | 2024.10.24 |