데이터베이스가 필요한 이유?

모든 서비스는 데이터를 만들어내고, 그 데이터의 저장을 필요로 한다.

 

예를들어 우리가 자주 사용하는 카카오톡, 쿠팡만 해도 유저 등록, 채팅 기록 저장, 구매 관련 정보 저장 등등 데이터의 저장은 필수다.

 

이 데이터는 프로덕션 관계형 데이터베이스(RDBMS)에 저장한다. 이는 데이터 웨어하우스 관계형 데이터베이스와 달리 서비스의 운영에 필요한 데이터를 저장하는 곳이므로 (MySQL, PostgreSQL 등) 빠른 처리속도가 중요하다.

 

관계형 데이터 베이스는 이 데이터를 구조화된 테이블들의 집합으로 구성하여 저장하고 관리한다.

 

이 관계형 데이터 베이스와 비교되는 다른 데이터 베이스로 데이터 웨어하우스가 있다. 이는 처리속도 보다는 구조화된 큰 데이터를 처리하는 것이 중요하다.

 

- 관계형 데이터베이스 종류

1. 프로덕션 관계형 데이터 베이스 : 빠른 처리속도에 포커스를 맞춘 데이터 베이스 (ex: MySQL, PostgreSQL) [focus speed]
2. 데이터 웨어하우스 관계형 데이터 베이스 : 얼마나 많은 데이터를 처리할수 있는 지 그 양에 포커스를 맞춘 데이터 베이스 (ex: 구글 클라우드 BigQuery, Snowflake, 아마존 클라우드의 Redsjoft 등등) [focus scalability]

프로덕션 관계형 데이터 베이스는 고객의 입장에서 서비스를 사용할때 그 서비스가 많은 트래픽을 받아도 속도 처리를 빠르게하는 것이 중요하다.

반대로 데이터 웨어하우스 관계형 데이터베이스는 고객의 입장이 아닌 회사의 입장으로 봐야 한다.

[데이터 웨어 하우스의 이점]

회사에 필요한 모든 데이터를 한곳에 저장하면 거기서 생기는 이점들이 있다.

한곳에 저장하기 전에는 뭔가 하나를 분석하려고 해도 특정사람이 여기저기 데이터를 다운받고 엑셀, 구글 스프레드시트에 데이터를 올린뒤 매뉴얼하게 join 하여 시간이 오래걸리면서 또 실수로 인한 에러가 굉장히 잦게 발생하는 상태에서 데이터를 분석해야 한다.

근데 이 데이터를 누가 한군데 모아서 수집해 줄 수만 있다면 데이터 수집을 위한 수거가 없어진다. 실수를 할 가능성도 굉장히 낮아진다. 그래서 데이터 웨어하우스는 데이터 직군에서 이런 데이터를 통해 더 좋은 의사결정을 하도록 한다. 또 회사의 서비스를 최적화 하는데 도움을 준다.

 

[프로덕션 데이터베이스가 데이터 웨어하우스에 포함된 이유]

보통 프로덕션 데이터베이스는 데이터 웨어하우스에 포함된 형태이다.

이렇게 안하면 만약 회사 내부 직원들이 고객들이 사용하는 프로덕션 데이터베이스에 DML을 날리게 되는데, 여기서 실수로 굉장히 많은 DML을 날리게 되면 프로덕션 데이터베이스의 속도가 줄어들게 된다.

따라서 이게 서비스 사용자의 체감 속도를 느리게 할 수 있기 때문에, 데이터 웨어하우스 안에 프로덕션 데이터베이스를 복사해서 저장한다.

 

- 데이터 순환 구조 : 프로덕션용 데이터베이스와 데이터 웨어하우스

웹 사이트를 통해 방문하게 되면 유저의 정보가 데이터베이스에 저장되는데 이를 프로덕션용 관계형 데이터베이스에 저장하여 필요할 때마다 유저에게 정보를 제공한다.

 

또한 사이트에 접속하는 여러 트래픽과 유형들을 프로덕션용 관계형 데이터베이스 뿐만아니라 데이터 엔지니어들이 데이터 웨어하우스에 데이터를 정제하여 적재하고, 데이터 분석가들이 그 데이터를 보며 추이를 분석하고, 데이터 사이언티스트 들이 데이터를 기반으로 사용자에게 추천상품을 주는 등의 작업을 수행하게 된다. 이를 통해 다시 사용자에게 데이터를 제공하게 된다.

 

즉, 프로덕션용 데이터 베이스에서 데이터 웨어하우스로 데이터가 적재되면서 데이터가 순환되게 된다.

 

 

- 백엔드 시스템 구성도

시스템 구성의 변화 [2 Tier]

 

클라이언트와 서버 두 개의 티어로 구성되며 이는 보통 데스크탑 응용프로그램에서 사용되는 아키텍쳐이다.

 

이 아키텍쳐에서 클라이언트는 사용자가 사용하는 UI이면서 비즈니스 로직을 처리한다(front-end). 그리고 서버단이 데이터 베이스가 된다(back-end).

 

[장점]

1. 쉽고 빠르게 개발할 수 있고 시스템 구축이 어렵지 않다.
2. 어플리케이션 구조가 단순하다.
3. 개발 비용이 저렴하다

[단점]

1. 클라이언트와 DB가 직접적으로 붙기 때문에 안정성에 문제가 있다.
2. UI와 비즈니스 로직을 클라이언트에서 모두 관리하므로 부하가 걸리기 쉽다.
3. 비즈니스가 점점 복잡해지면 관리하기가 어려워 진다.

이러한 단점으로 인해 웹 서비스는 3 Tier 아키텍쳐로 변화하게 된다.

 

시스템 구성의 변화 [3 Tier]

 

 

이 아키텍쳐는 웹 서비스에서 많이 이용되며 UI를 클라이언트가 담당하고 비즈니스 로직을 어플리케이션 서버가 담당하고, 데이터베이스를 데이터베이스 서버가 관리하게 된다.

 

이러한 시스템 구성의 예로 Spring Boot를 들 수 있다. Spring Boot는 백엔드 프레임 워크중 하나로 자바 기반이다.

 

스프링 부트를 통해 클라이언트로 부터 API 요청을 받아 비즈니스 로직을 처리하고 영속성 레이어가 데이터베이스 서버로 데이터의 기록을 남기게 된다.

 

[장점]

1. 클라이언트와 DB가 직접적으로 붙지 않고 어플리케이션 서버가 미들웨어로 존재하므로 보안에 용이하다.
2. 확장에 용이하다.
3. 비즈니스 로직과 UI를 분리할 수 있다.

 

- 스키마 종류

데이터 베이스를 사용하는 이유를 알았다. 그럼 이제 우리 서비스를 운영하는데 필요한 데이터를 어떤 테이블들로 나눠서 저장할 것인지 잘 설계하는 것이 중요하다. 이를 데이터 모델링 이라고 한다.

이 데이터 모델링을 어떻게 하느냐에 따라 스키마 종류가 나뉘게 된다.

 

1. Star Schema

• 데이터를 논리적 단위로 나눠 저장하고 (primary key) 필요시 조인 (조인이 시간, 리소스를 써야 하기 때문에 속도 저하 효과를 가져올 수 있다.)
• 스토리지의 낭비가 덜하고 업데이트가 쉽다.
• 프로덕션 데이터베이스용 관계형 데이터베이스에서 보통 스타 스키마를 사용하여 데이터 저장

 

2. Denormalized Schema

 

• nosql이나 데이터 웨어하우스 에서 사용하는 방식
• 단위 테이블로 나눠 저장하지 않고 별도의 조인이 필요없는 형태임
• 이는 스토리지를 더 사용하지만 조인이 필요 없으므로 빠른 계산이 가능

 

데이터 웨어 하우스는 스타 스키마를 써도 상관 없다. 디노멀라이즈드 스키마도 마찬가지로 사용 가능하다. 왜냐면 데이터 웨어하수으는 프로덕션 데이터베이스처럼 사이즈의 제약을 덜 받는 구조다.

프로덕션 데이터베이스는 기본적으로 컴퓨터 한대에 들어가는 데이터베이스이다. 그러다 보니 컴퓨터 한대가 가져올 수 있는 메모리나 디스크의 크기에 한계가 있다. 그걸 넘어가는 순간 더이상 데이터 처리를 못한다.

근데 데이터 웨어하우스는 컴퓨터 한대짜리 솔루션이아니라 다수의 컴퓨터로 구성되므로, 메모리나 디스크가 모자르더라도 컴퓨터 한대를 또 붙이면 된다. (이를 cluster 라고한다.) 즉 cluster 구조기 때문에 데이터 웨어하우스는 공간적인 제약이 프로덕션 데이터베이스보다 덜하다.

그래서 스토리지를 조금 더 낭비해도 문제가 없다.

nosql은 조인하여 데이터를 참조하는데 제약이 많기 때문에 denormalized schema처럼 모든 데이터를 적어 놓는게 일반적임