본문 바로가기

IT 트렌드

빅데이터(BigData) 7부 - 수평확장(Scale Out)은 RDB보단 NoSQL이지!

반응형

이전 글에서 수직확장(Scale Up)과 수평확장(Scale Out)에 대해 알아보았다. 아직 못 본 사람들은 아래 링크에서 먼저 보고 오자!

 

빅데이터(BigData) 6부 - 수직확장(Scale Up)과 수평확장(Scale Out)

 

이전 글에서 말했지만 현재 기업이 놓인 상황에 따라 수직확장이 더 좋을 수도 수평확장이 더 좋을 수도 있다. 하지만 빅데이터에서는 수직확장보다는 수평확장이 더 좋다. 그래서 NoSQL을 사용하는 것인데 그 이유에 대해서 차근차근 알아보도록 하자.

RDB와 수평확장

RDB에서 수평확장을 할 때 사용하는 단어가 있는데 바로 샤딩(Sharding)이다. 샤딩이라는 단어보다는 이 RDB는 어떻게 수평확장을 할 수 있을지 함께 보자.

 

수평확장 구성부터 고민해 봐야 할 것이다. 아래 그림을 보면서 생각해 보자.

 

한 개의 디바이스가 두 개의 디바이스로, 데이터도 두 개로 나누어 진다.

 

즉, 수평확장이 되면 디바이스도 두 개가 되지만 각 디바이스에 하나의 데이터가 두 개로 분리되어 저장되어야 한다. 두 디바이스에 똑같은 데이터가 들어가면 수평확장의 의미가 없다는 것은 충분히 이해하고 있을 것이라 생각한다. 자 그럼 이제 실제 데이터를 분리를 생각해보자.

 

아래 표(이하 '테이블')가 하나 있다. 이 테이블을 수평확장하려면 어떻게 해야 할까?

 

번호 이름 성별 나이
1 철수 18
2 영희 18
3 슬기 33
4 승범 33

 

더보기
번호 이름 성별 나이
1 철수 18
2 영희 18

 

번호 이름 성별 나이
3 슬기 33
4 승범 33

위의 방식처럼 두 테이블로 나누면 정답이다. 어느 부분에서 자를지는 데이터 관리하는 사람의 역량이니 방식만 알고 가자.

 

그러면 아래 그림과 같이 A 디바이스에는 번호가 1~2번 데이터가, B 디바이스에는 3~4번 데이터가 있다.

 

수평확장으로 분산시킨 결과

 

자, 그림만 보면 아주 간단해 보이지만 조금씩 확장시켜 보자.

 

확장 1. 만약 새로운 디바이스 C를 추가한다면... 어떻게 될까?

다시 새로운 규칙으로 데이터 구간을 잘라야 한다. 그렇게 되면 범위-디바이스 테이블도 변경되어야 한다.

확장 2. 관계 테이블이 존재한다면... 어떻게 될까?

관계의 추가와 디바이스의 추가

 

현재 위 그림은 단순히 사용자에 관한 테이블만 나타낸 것이다. 하지만 '사용자가 영상을 보았다.' 또는 '사용자가 영상을 올렸다.'와 같은 관계는 어떤 기준으로 나누어 따로 저장해야 하는가?

 

또, 사용자는 A 디바이스에서 찾을 수 있었는데 '사용자가 영상을 보았다.'와 같이 관계를 나타내는 데이터는 B 디바이스에 찾아야 한다면... 어떻게 할 것인가? 그리고 그 영상은 새롭게 추가된 C 디바이스에 있다면...?

 

특정 사용자에 대한 데이터를 추출하기가 너무 어렵다는 것이다. 최악의 경우 1번 사용자는 A디바이스에 있는데 관계는 B디바이스, 그 영상은 C디바이스에 있을 수도 있다는 것이다.

 

여기까지 우리는 관계가 복잡하고 데이터 많으면 많을수록 RDB는 수평 확장에 대한 관리가 한없이 복잡해진다는 것을 알 수 있다. 

 

샤딩에 대해 조금 더 자세히 알고 싶다면... IT 관계자라면 여기를 참고하자.

NoSQL과 수평확장

NoSQL에 대해 반드시 이해를 해야지만 지금부터의 내용을 이해할 수 있다. 혹시 NoSQL에 대해 모른다면 아래 글을 먼저 보고 오자.

 

빅데이터(BigData) 5부 - NoSQL(Not only SQL) 왜 너가 선택되었니?

 

자, NoSQL은 전부 이해했다고 가정하고 수평확장을 해보자.

 

NoSQL은 특정 컬렉션에 모든 데이터가 저장되는 형태로 데이터 중복이 있다. 그렇기 때문에 분산을 시킬 때에는 단순히 구간만 정해서 자르면 된다.

 

이전 글(5부)에서 사용했던 예시를 잠깐 가져왔다.

 

사용자 집합(사전)

1 : 이름 : 철수
     올린 글 : 
              1 : 이름 : 10분으로 빅데이터...
                   영상시간 : 621
                   경로 : 내문서
              n : ...
     본 글 : 
              2 : 이름 : 10분으로 IT 트렌드...
                   영상시간 : 621
                   경로 : 내문서
              n : ...
2 : 이름 : 영희
     올린 글 :
              2 : 이름 : 10분으로 IT 트렌드...
                   영상시간 : 621
                   경로 : 내문서
              n : ...
     본 글 : 
              1 : 이름 : 10분으로 빅데이터...
                   영상시간 : 621
                   경로 : 내문서
              n : ...
...


위 데이터는 자르면 아까 RDB에서 자른 결과와 같이 나올 것이다.

 

수평확장으로 분산시킨 결과

 

하지만 RDB와 다른 것은 관계를 위해서 범위-디바이스 테이블이 더 많이도 필요 없다. 왜냐하면 1번 사용자가 본 영상정보는 모두 A디바이스 내에 존재하기 때문이다. 그래서 계속적으로 확장하더라도 아래와 같은 형태를 가진다.

 

디바이스 C 추가 결과

 

어떤가? 훨씬 RDB보다 간단하다는 생각이 들지 않는가?

필자의 사견

사실 지금까지 설명한 것은 누구나 이해할 수 있게 돕기 위해 정말 간단한 예시만을 가지고 설명한 것이다. 당연히 수없이 많은 예외상황이 존재하고 RDB, NoSQL을 함께 사용해야 하는 경우도 반드시 발생할 것이다. 하지만 현재 제공되고 있는 서비스들의 형태를 생각해보면 NoSQL이 적합하다는 것을 알 수 있다.

 

유튜브 첫 화면 들어가면 내가 구독한 사람들 영상 및 좋아할 영상을 보여준다. 인스타그램을 들어가도 내가 팔로우한 사람들의 사진들이 뜬다. NoSQL은 '나'라는 사람의 데이터에 집중해서 데이터를 저장하기 때문에 내가 누군지만 알면 데이터를 한 번에 다 가져올 수 있다는 장점이 있다. NoSQL은 RDB처럼 관계에 집중하는 것이 아니라 '나'라는 객체에 집중하는 구조이기 때문이다.

 

다음편에서는 세부적인 내용이 아닌 빅데이터의 장단점에 대해 알아보도록 하자.

반응형