메모리 증설이 불가능하다면 파티셔닝이 필요하다.

파티셔닝이란 테이블A와 테이블B를 서로 다른 서버에 놓아서 분산하는 방법이다. 파티셔닝은 국소성을 활용해서 분산할 수 있으므로 캐시가 유효해서 효과적이다.

파티셔닝을 전제로 한 설계

파티셔닝에 관한 것 중 또 하나 잊어서는 안 될 것이 파티셔닝을 전제로 한 설계, 이것이 중요하다.

가끔 이 두 테이블을 함께 사용하고자할 때 JOIN 쿼리를 던진다. 그러나 JOIN 쿼리를 던지기 위해서는 entry와 tag를 분할할 수 없다. (여기서 분할은 다른 머신으로 나눈다는 의미다)

아래 그림에서 entry 테이블과 tag 테이블을 다른 머신에 올리고 싶은데, MySQL에는 서로 다른 서버에 있는 테이블을 JOIN하는 기능이 기본적으로는 없다. 그러므로 JOIN을 사용한다면 tag 테이블과 entry 테이블을 다른 서버에 위치시킬 수 없다.

하지만 JOIN을 사용하지 않는다면, 예를들어 tag테이블에 질의해서 'perl'이라는 태그를 포함하는 엔트리의 eid를 1, 2, 5, 8, 10과 같이 쭉 뽑아내서, 이 ID를 포함하는 entry 테이블의 레코드를 뽑아내는 것(3)과 같은식으로 쿼리를 둘로 나눠서 하면 뽑아낼 수 있다.

따라서 기본적으로 JOIN 쿼리는 대상이 되는 테이블을 앞으로도 서버 분할하지 않을 것이라고 보장할 수 있을때에만 사용한다.

JOIN 배제 - where ... in ... 이용

INNER JOIN을 안쓰고도 동일한 결과를 얻을 수 있다.

select url 
from entry INNER JOIN bookmark on entry.eid = bookamrk.eid
where bookmark.uid = 169848 
limit 5;

위 대신

select eid from bookmark where uid = 169848 limit 5;

select url from entry where eid in (0, 4, 5, 6, 7);

파티셔닝의 상반관계

파티셔닝의 좋은 점은 부하가 내려가고 국소성이 늘어나서 캐시 효과가 높아진다는 점이었다. 한편으로는 나쁜 점도 물론 있다.

운용이 복잡해진다

서버가 둘로 나뉘어지고, 용도가 다른 서버가 생기는 것이다. 이 서버는 무슨 일을 하고 저 서버는 무슨 일을 하는지를 머릿속으로 파악해야하므로 운용이 복잡해진다.

고장률이 높아진다.

대수가 늘어나는만큼 고장확률이 높아진다. 서버가 4대 있을 때 분할하면 8대가 필요하다.

다중화에 필요한 서버 대수는 몇 대?

애초에 왜 A 서버가 4대 필요할까?
마스터가 1대 있고, 슬레이브가 3대라면, 슬레이브나 마스터가 고장나더라도 괜찮다 (슬레이브를 마스터로 해주면된다)

만약 3대가 1세트로 되어있다면, 슬레이브가 고장났을 때 새로운 db 서버에 데이터를 복사해야하는데 이때 서비스를 중지해야 한다.

애플리케이션의 용도와 서버 대수

분할하면 4대 였던 것이 갑자기 8대가 되었다. 3대로 분할하면 12대가 되어 점점 더 늘어나게 된다. 무정지가 필수 조건인지 여부는 해당 애플리케이션의 용도에도 의존하므로 반드시 4대가 필요하다고는 할 수 없다.