https://blog.naver.com/getinthere/222361419686
몽고DB 19강 - 샤딩 고급
1. 샤딩 키 선정 방법 - 샤딩 키는 직접 지정할 수 있는데 이때는 무조건 인덱스가 필요하다. 찾을때는 좋...
blog.naver.com
1. 해시 (순차적인 단순 번호) Key base Shading
들어오는 데이터가 1부터 9일 때
순서대로 들어오는 번호 데이터를 잘 저장할 수 있다.
_id:1 ~ 100 ~ 1000
샤드키 : _id
1 -> 해시 function -> asdf3n2jvasdv 변환
알아서 밸런스 맞춰서 샤드에 저장된다.
몽고DB에 데이터를 INSERT 하면 오브젝트 아이디가 생성되는데
timestamp 현재 시간을 기준으로 만들어진다.
timestamp + random value + counter 값을 해시값으로 변환하는것이다.
무조건 유일하고 순차적이다.
key base shading을 해시로 변환하지 않고 사용할 수도 있다.
id 자체를 인덱스로 거는 것이다.
이 경우에는 샤드 증설이 어렵다.
2. index로 직접 걸기
들어오는 데이터가 1부터 9일 때
(= 번호에 샤드키를 걸면)
(1) 범위로 거는 것 Range base Shading
1~9
1, 2, 3 4, 5, 6 7, 8, 9
(1보다 크거나 같고 4보다 작음), (4보다 크거나 같고 7보다 작음), (7보다 크거나 같고 10보다 작음)
단점 : 들어오는 데이터가 1부터 3일 때는 하나의 샤드만 사용하게 된다.
샤드의 가중치 설정이 힘들어진다.
병렬 처리가 되지 않는다.
상황에 따라 다르지만 일반적으로 이렇다.
장점 : 샤드 증설이 쉽다.
추가적으로 데이터를 받을 때 범위 지정만 해주면 된다.
기존 샤드를 건드릴 필요 없다!
만약 한글 이름 데이터가 들어온다고 할 때
가~하
홍길동 임꺽정 장보고
이름1 이름2 이름3
내가 특정 이름을 찾고 싶을 때 어디서 찾아야 할지 모르겠다.
김 씨 성을 가진 이름을 찾기 위해 모든 샤드를 찾아봐야겠다.
이때는 범위로 지정해두는 게 찾기 더 쉽다.
가~라 마~사 자~하
(2) 순차적으로 저장
들어오는 데이터가 1부터 9일 때
1 2 3
4 5 6
7 8 9
장점 : 가중치 설정이 매우 쉽다.
번호라는 것은 무한하기 때문에 끝이 없다.
5~8000까지 데이터가 들어와도 가중치 설정이 쉽다.
단점 : 샤드 증설이 어렵다.
샤드를 증설하는 순간 지금까지 했던 샤드키 설정 알고리즘을 다 삭제하고 새로 만들어야 한다.
리빌딩을 하지 않으면 데이터가 다 꼬이기 때문이다.
리빌딩을 하게 되면 기존 서버가 죽어버린다.
기존 서버를 죽이지 않고 하기 위해서는 전체 구성에 대한 레플리카셋이 하나 더 필요하다.
비용이 매우 많이 든다.
죽일 수밖에 없는 것이다.
만약 데이터가 들어올 때 샤드키를 지정해주는 특정 아주 좋은 방법이 있다면 다른 방법들은 없어졌을 것이다.
아직 없어지지 않았다는 것은 상황에 따라 다르게 사용하기 때문이다.
이름으로 SELECT를 해야 한다면 범위로 지정해주는 게 좋고,
숫자로만 SELECT 해야 할 때는 순차적으로 저장해주는 게 좋은 것처럼 말이다.
ex) 블로그 서비스
몽고에 다음과 같은 데이터가 있다고 해보자.
{ _id:1, title:"스프링 리플렉션", username:"최주호" }
{ _id:2, title:"스프링 IoC", username:"최주호" }
{ _id:3, title:"스프링 DI", username:"최주호" }
{ _id:4, title:"스프링 JPA", username:"최주호" }
{ _id:5, title:"스프링 리플렉션", username:"백기선" }
{ _id:6, title:"스프링 JPA", username:"백기선" }
title에 중복되는 데이터가 있다고 해서 인덱스를 안 만들지 않는다.
검색 : 리플렉션
만약 인덱스가 걸려있지 않으면 풀스캔하여 title에 "리플렉션"이 포함된 게시글을 찾아낸다.
데이터가 6개밖에 없을 때는 풀스캔하는게 유리하지만
데이터가 몇십억 건이 쌓였을 때는 풀스캔은 최악의 방법이다.
몇십억 건의 게시글 중에 리플렉션이라는 게시글은 전체에서 적은 부분일 것이다.
내가 찾아야 할 데이터가 통상적으로 15% 이하이여야 한다.
중복이 적어야한다는 말이다.
전체 데이터에서 차지하는 데이터가 적고, 자주 검색이 된다는 필드에는 인덱스를 걸어줘야 한다.
이때 샤드키는 title이 되겠다.
title이 비슷한 것 끼리 저장된다.
블로그와 같은 서비스에는 title을 샤드키로 설정하는 게 매우 적절하다.
블로그에는 글을 자유롭게 작성하기 때문에 데이터가 몰릴 일이 적다.
검색했을 때 select가 빠를 것이다.
샤드키를 뭘로할지는 필드로 결정하는 것이다.
검색 : 최주호
우리 서버는 이름으로 더 자주 검색하는지 title로 검색을 더 자주 하는지를 판단하여
샤드키를 username으로 할지 title로 할지 결정한다.
사용자의 UX를 분석하여 결정해야 한다.
분석하는 사이트를 구글에서 제공해준다.
구글 애널리틱스!!
ex) 우유 판매 서비스
관리자가 한 명 있고 직원이 3명 있다.
우유를 싣고 트럭이 들어온다.
우유의 종류에는 흰 우유, 딸기우유, 초코우유 3가지가 있다.
원래 1번 직원에게 3가지 우유를 모두 다 보냈다.
1번 직원에게만 우유들이 50억개가 쌓여있다.
관리자가 1번 직원에게 흰 우유만 달라고 요청했을 때
50억개를 다 찾아서 흰 우유를 빼줘야 한다.
여기서 샤딩의 핵심이 나온다.
수평적 분할을 한다.
이때 분할의 기준을 어디에 둘지 설정하는 게 샤드키 설정이다.
1번 직원에게는 흰 우유,
2번 직원에게는 딸기우유,
3번 직원에게는 초코우유를 보낸다.
각각의 직원에게 row가 적게 쌓이기 때문에 수평적 분할이라고 한다.
이게 샤딩이다.
이때 샤드키는 우유의 이름(title)이 된다.
이렇게 저장하면 각각의 직원에게 50억건이 아닌 15억건씩 가지고 있다.
흰 우유를 찾고 싶을 때 1번 직원에게로만 가면 된다.
저장 시에도 분산하여 저장하기 때문에 I/O가 줄어든다.
어차피 하드디스크에 저장할 때는 하드디스크가 많을수록 좋다.
핵심 : 분산 저장을 한다는 것은 수평적 분할을 한다는 말이다.
수평 분할을 하면 데이터가 쪼개지니까
적은 양에서 데이터를 찾는 것과 많은 양에서 데이터를 찾는 것은 퍼포먼스 자체가 다르다.
그래서 도서관에서 각각의 책에 카테고리가 나눠져 있는 것이다.
찾기가 매우 편하다.
이때 영어책만 찾을 때는 영어 카테고리에 가서 찾으면 되는데
영어, 수학, 과학책을 다 찾고 싶을 때는 어떻게 해야 할지 생각해봐야 한다.
아 영어, 수학, 과학책이 다 필요하면 수험생이구나!
수험생을 위한 카테고리를 따로 만들어둬야지!
마찬가지로 손님이 흰 우유를 찾을 때는 잘 나눠져 있는 것이지만
우유를 찾으려면 3군데 다 찾아가야 한다.
샤딩을 할 때는 많은 시행착오가 필요하다.
정답이 없다!!
[출처]
https://cafe.naver.com/metacoding
메타코딩 : 네이버 카페
코린이들의 궁금증
cafe.naver.com
메타 코딩 유튜브
https://www.youtube.com/c/%EB%A9%94%ED%83%80%EC%BD%94%EB%94%A9
메타코딩
문의사항 : getinthere@naver.com 인스타그램 : https://www.instagram.com/meta4pm 깃헙 : https://github.com/codingspecialist 유료강좌 : https://www.easyupclass.com
www.youtube.com
