partitionig?
DB 테이블을 더 작은 테이블로 나누는 것을 의미한다
paritioning에는 vertical partitioning과 horizontal partitioning이 있다
vertical partitioning?
vertical partitioning은 column을 기준으로 테이블을 나누는 것을 말한다
정규화가 대표적으로 vertical partitioing의 한 종류이다
이미 정규화가 된 테이블이라도 여러 이유로 vertical partitioning을 할 수 있는데, 주로 다음과 같은 이유일 때이다
* 자주 사용되는 column들을 따로 분리하고 싶을 때
* 사이즈가 큰 column이 자주 사용되지 않을 때
* 민감한 정보를 가지는 column들을 따로 분리해서 조금 더 보안을 강화하고 싶을 때
horizontal partitioning?
반면 horizontal partitioning은 row를 기준으로 테이블을 나누는 것을 말한다
테이블에 엄청나게 많은 데이터가 쌓일 것으로 예상될 때 이 방식을 사용할 수 있다
테이블에 데이터가 많이 쌓이면, 아무리 인덱스가 걸려있다고 할지라도, 뒤로 가면 갈수록 검색 시간과 쓰기(삽입/삭제/수정) 시간이 길어질 수 있기 때문이다
그래서 horizontal partitioning은 동일한 스키마를 가지는 테이블을 여러 개 두고 각 테이블에 데이터를 분배해서 저장함으로써 성능적으로 이점을 가져가는데 그 목적이 있다
horizontal partitioning에서 parition key가 중요한 이유
대신 각 데이터가 어떤 partition(= 나눠진 테이블)에 저장될지를 정해야 하는데, 이때 사용되는 것이 partition key다
즉, 특정 column(s)을 partition key로 지정하면, 저장하려는 데이터의 parition key의 값에 따라 어떤 partition에 저장될지가 정해진다
parition key를 통해 데이터를 분배하는 방식은 여러 가지가 있는데 그중에 내가 느끼기에 가장 자주 사용되는 방식은 hash 기반의 horizontal partitioning이다
이 방식에서는 hash function을 통해 데이터들이 어떤 parition(= 나눠진 테이블)에 저장될지가 결정된다
hash 기반 horizontal partitioning 예제
만약 온라인 쇼핑몰에서 주문 정보를 저장하는 order라는 테이블이 있다고 가정해 보자
order 테이블의 스키마는 아래와 같다
order_id | user_id | product_id | cnt |
처음 DB를 설계할 때 이미 order 테이블에 매우 많은 주문들이 저장될 거라고 예상했기 때문에 hash 기반의 horizontal partitioning을 order 테이블에 적용했다
그래서 order 테이블을 order_0, order_1, order_2, order_3, 이렇게 총 네 개의 테이블로 나눴다
이어서 parition key를 정해줘야 하는데, 서비스에서 가장 많이 사용될 패턴은 사용자 별로 주문 정보를 읽어오는 것이라고 예상할 수 있기 때문에 user_id를 parition key로 정했다
그러면 이제는 데이터를 각 테이블에 분배하여 저장하기 위해 hash function을 정의해야 한다
user_id를 input으로 받고 output은 테이블이 네 개니까 0, 1, 2, 3 중에 하나가 나올 수 있도록 hash function을 구현한다
이때 hash function의 output이 랜덤 하면서도 비슷한 비율로 나올 수 있도록 hash function을 잘 구현하는 것이 중요하다
그래야 각 테이블에 균등하게 데이터들을 저장할 수 있다
hash 기반 horizontal partitioning 장점
이제 주문 정보를 DB에 저장하려고 할 때마다, hash function에 주문자의 id를 input으로 넣고 그렇게 해서 나온 output(= hash 값)에 대응하는 테이블로 가서 주문 정보를 저장하면 된다
가령 output이 3이라면 order_3 테이블에 해당 주문 정보를 저장한다
이렇게 하면 만약 어떤 사용자가 자신의 주문 정보들을 보고 싶어 할 때, 해당 사용자의 주문 정보는 네 개의 테이블 중 오직 하나에 모두 저장돼 있을 것이기 때문에 조회할 때 성능적으로 이점을 가져올 수 있다
즉, 나눠지기 전에 하나의 테이블로 저장돼 있을 때보다 (간단하게 생각하면) 검색 시간이 1/4로 줄어들어서 더 빨리 응답할 수 있게 된다
쉬운코드는 본질에 충실합니다
👉 paritioning vs sharding vs replication 비교 영상 보러 가기