SECTION 4.7 - 파티셔닝, 샤딩, 레플리케이션

---

파티셔닝 ( Partitioning )

[ YOUTUBE 쉬운코드 -DB ]

database table을 더 작은 table들로 나누는 것

• 종류

  • vertical partitioning

    column을 기준으로 table을 나누는 방식

  • horizontal partitioning

    row을 기준으로 table을 나누는 방식

• vertical partitioning

  column을 기준으로 나눔

  정규화도 일종의 vertical partitioning
  

  앞서 정규화를 하는 이유는 DB에 중복된 데이터가 저장되지 않도록 하기 위함과 INSERT, UPDATE, DELETE를 하게 될때 생기는 이상 현상을 방지하기 위함이라고 학습했음

  처음에는 한개의 테이블에서 칼럼을 기준으로 정규화 수행을 통해 최종적으로는 4개의 테이블에 나누어서 데이터를 저장할 수 있게 됨
  => 이 정규화 과정 또한 vertical partitioning 이라고 말할 수 있음

  • 다른 예시 - 게시판

    화면에 게시글에 관련된 정보들을 보여주기 위해 쿼리문이 존재할것이고 ARTICLE이라는 테이블에서 특정 조건을 만족하는 게시글들을 읽어오게 됨.

    여기서 말하는 특정 조건은 기간,작성자,특정 키워드가 될 수 있음
    위에서 보여주는 화면에서는 content라는 정보는 필요가 없기 때문에 실제로 가져오지는 않음

    위 예시에서 쿼리문이 동작할 때 ARTICLE이라는 테이블에서 일단 모든 데이터들을 가지고 온 후 필요한 데이터( id ~ comment_cnt )만 출력하는 방식으로 이루어 짐
    => 화면에서는 content는 필요없기때문에 필터링을 해주었으나 실제 동작에서는 content정보까지 읽어서 메모리에 올린다음에 원하는 속성만 필터링을 함

    화면에서 사용하지 않는 content라는 속성 때문에 I/O에 부담이 생김 => 시간적인 낭비

    이때 vertical partitioning을 통해 해결!
    

    칼럼을 기준으로 잘라냄

이미 정규화가 되어 있더라도 더 좋은 performance를 위해 verical partitioning을 수행!

그외 에도 민감한 정보에도 접근하기 어렵게 하기 위해 사용하기도 하고 자주 사용하거나, 자주 사용하지 않거나 하는 속성에 대해서도vertical partitioning을 수행할 수 있음

• horizontal partitioning

  row를 기준으로 나눔

  예를 들어 설명해 보자
  위테이블은 유튜브와 비슷하다고 생각하면 됨

  of users : 유저 수
  of channels : 채널의 수
  of max sub : 이 테이블이 가질 수 있는 최대의 row 수
  => 유저 수 x 채널 수 = 이 테이블의 최대 row

  즉, 다시말해 유저 수나 채널 수가 늘어나면 row의 최대치는 증가할 것

  그러면서, 이제 생각해야할 부분이 있다

  • 테이블에 저장된 데이터들이 많아지면 인덱스의 크기도 커짐

    테이블 읽기/쓰기가 있을때 마다 인덱스에서 처리되는 시간도 조금씩 늘어남

이때 사용하는 것이 horizontal partitioning

• hash를 기반으로한 horizontal partitioning

  • user_id를 input으로 받아 output으로 { 0,1 }을 받음
  • SUBSCRIPTION_0, SUBSCRIPTION_0 2개의 테이블을 만듬
  • user_id를 hash_func에 넣어서 나오는 output에 따라 2개에 테이블에 따로 저장되게 함
    => 결국 같은 유저는 두개의 테이블 중 한곳에 각각 저장되게 됨

  이때 user_id를 기준으로 나누어 저장되는것이기 때문에 이를
  => partition key라고 부름

• partition key 생각해보기

  user_id로 구독한 채널들 정보를 select로 조회하고 싶을 경우
  vs
  user_id가 N인 채널을 구독한 user_id를 select로 조회하고 싶을 경우

  후자일 경우 partition key와는 상관없는 조건으로 조회를 하기 때문에 결국 모든 테이블을 스캔해야함

• 가장 많이 사용될 패턴에 이 partition key를 정하는것이 중요하고 또한 데이터가 균등하게 분배될 수 있도록 hash func를 잘 정의하는것도 중요함
• 이미 나누어져있는 파티션에서 새롭게 파티션을 추가하는것은 매우 까다롭기 때문에 처음 파티셔닝을 설계할때 잘 설계해야함

---

샤딩 ( Sharding )

horizontal partitioning 처럼 동작

각 partition들을 서로 다른 DB서버에 저장하는것을 말함

모든 partition들을 같은 DB서버에 저장

위와 같은 경우는 horizontal partitioning이라고 함

서로 다른 DB 서버에 저장할 경우 트래픽을 분산시킬 수 있음
샤딩 = 부하(load)를 분산시키는것이 목적

이 때 partition key를 shard key라고 부르고 각 partition을 shard 라고 부름

레플리케이션 ( Replication )

DB서버에 발생한 문제를 어떻게든 해결해주는 방식중 하나

그림에서 각 서버는 같은 데이터를 가지고 있음
=> 원래 있던 서버의 UPDATE, DELETE, INSERT 정보를 항상 싱크를 맞추면서 원본과 같게 유지

이때 각각을 부르는 호칭이 있음

• 위쪽 원본 서버 (실제 read/write 동작) : master / primary / leader
• 아래쪽 copy 서버 : slave / secondary / replica

• High availability (고가용성)
  Replication을 사용하게 되면, 원래 사용하던 서버에서 문제가 생겼을 경우 빠르게 서비스에 타격이 없도록 할 수 있게 해줌

  장애 상황이 발생했음에도 계속해서 서비스를 유지될수 있게 해주는 이러한 특성을 고가용성이라고 말함

  • Replication을 사용할 경우 HA보장가능, read 쿼리중 일부를 분산시켜줄 수 있음 (부하를 줄여줌)