Search
Duplicate
📒

[비즈니스 요구사항 MongoDb] 01-1. NoSQL 등장배경(SQL vs NoSQL)

상태
수정중
수업
비즈니스 요구사항 MongoDB
주제
기본개념
4 more properties
참고

데이터베이스의 역사

초기의 데이터베이스 관리 시스템

NOTE
1970년대 RDBMS가 등장하기 전 → 파일 시스템으로 주로 이루어짐!
폴더와 파일로 데이터를 저장했으며 많은 문제가 생김

기존 파일 처리 시스템의 대표 문제점

1.
데이터 종속의 문제
데이터가 특정 사용자, HW, SW에서만 사용되는 제한이 생긴다.
ex) 위 그림의 애플리케이션2가 파일 1, 3에 접근하지 못한다.
2.
데이터 중복의 문제
애플리케이션 별로 데이터를 생성해야 하기 때문에, 동일한 데이터가 여러번 생성된다.
당시 디스크 가격을 생각하면 데이터 중복으로 인한 저장공간이 줄어드는건 상당히 컸다.
3.
무결성 훼손의 문제
중복 데이터가 커질수록 개별 데이터를 지속적으로 모니터링 하기 힘들어진다.
4.
동시 접근의 문제
파일 처리 시스템에서 다수의 사용자가 동시 접근하면 데이터 관리의 일관성이 떨어진다.
ex) 동시간에 데이터 1에 접근하면, 어느것이 반영되어야 하는지 어려움

관계형 데이터베이스

NOTE
데이터 구조의 논리 구성을 물리적인 저장 구조와 분리했다!
DBMS → 데이터의 CRUD를 위한 소프트웨어 패키지
DBMS는 다음과 같이 프로그램과 파일 사이에 존재하여 실제 파일이나 디스크에 데이터가 어떻게 저장되는지와 상관없이 개념, 논리적으로 접근하여 데이터를 사용하게 해준다!

관계형 데이터베이스 장점

데이터 중복 최소화
과거에는 디스크 가격이 비싼만큼 상당히 중요했다.
데이터의 일관성 유지
동일한 내용을 나타내는 2개의 데이터 중 하나만 변경된다면 모순성을 가지게된다.
데이터베이스 관리 시스템은 이러한 중복을 제어하고, 중앙 집중식 통제를 통해 일관성을 유지한다.
데이터의 무결성 유지
허용되지 않는 값이나, 부정확한 데이터가 들어오는걸 방지할 수 있다.

관계형 데이터베이스 단점 (대용량 데이터 처리의 어려움)

큰 규모의 데이터와 사용자를 대사응로 하려면 다음과 같은 요소가 필요하다.
대용량의 데이터 읽기
빠른 응답 시간
높은 가용성
RDB로 이를 구현하기 어려웠다. (설계부터 단일 서버에 맞춰져있기 때문)
단 sharding이나 partioning, replication 같은 기법들로 어느정도 해결가능
RDB의 경우 성능이 저하되면 스케일 업으로 문제를 해결했으나, 결국 한계가있다.
결국 DBA가 비정규화를 통해 스키마를 재설계 해야했다.

NoSQL 데이터베이스의 출현

NOTE
데이터의 일관성을 어느정도 포기하는 대신, 여러대의 컴퓨터에 데이터를 분산하여 저장하는 것을 목표로 등장했다!
다양한 종류의 NoSQL 종류가 있다.
서비스 자체에서 Scale-out을 지원해주기에 매우 편리함

등장배경

NoSQL이 등장하기 20년간, 데이터를 저장하는데는 RDBMS가 주로 사용되었다.
디스크의 가격이 부담스러워 최대한 공간을 절약해야 했다.
트랜잭션을 통한 안정적인 데이터 관리가 중요했다.
하지만 2009년 이후로 폭발적으로 데이터가 늘어나면서 RDBMS는 데이터를 처리하는 비용의 증가로 난관에 부딪힌다.
데이터와 트래픽의 급증 ⇒ 1대에서 실행되도록 설계된 RDBMS은 하드웨어 값이 비싸짐
장비의 성능을 올리는 방법은 비용이 기하급수적으로 증가하기 때문

No SQL의 특징

장점
클러스터 환경에서 대용량 서비스에 대응할 수 있다.
Join없이 조회가 가능해서 응답속도가 빠르다.
고정된 스키마가 없기에 일단 Value, Document 형태로 데이터를 넣어 빠르게 개발할 수 있다.
HA와 Sharding에 대한 솔루션을 자체적으로 지원하고 있어 Scale-out이 간편하다.
단점
RDBMS처럼 안정적인 트랜잭션을 보장하지 않는다.
업데이트가 자주 일어나는 테이블의 경우 부적합할 수 있다.
빠르게 개발할 수 있으나 유지보수는 어려울 수 있다.