대용량을 대비한 DB... 어떻게 설정해? (feat.PostgreSQL)

어딜 가나

강조되는 DB...

 

그치만 실무를 경험하지 못한 입장으로서

보통 어느 부분을 신경 써야 하는지 도통 감이 잡히지 않는다

 

오늘은

변칙적이지 않고 정해진 카테고리 내에서

각각 필드가 정해질 경우

고려해 볼 만한 사항에 대하여 이야기해 보겠다

 

예시로

임의로 작성된 로그 테이블을 살펴보자

 

DB with character varying(5)

 

여기서

category 칼럼을 살펴보자

 

현재 post 와 login 두 가지의 카테고리만

존재하는 것으로 보이고, 이들이 반복된다

 

지금은 최대 5의 char을 허용하고

단순 post 와 login 두 개지만

더 긴 글자수를 허용하고 두 개가 아닌

100개 1,000개 10,000개

혹은 그 이상의 카테고리가 있다면?

 

당연히 쿼리문의

성능은 저하될 것이다

 

그렇다면 어떠한 방안이 있을까?

 

예시로

변경된 로그 테이블을 살펴보자

 

DB with smallint

차이점을 살펴보면

 

character varying(5) 이 smallint 로 변경되었고

"login" 과 "post" 는 각각 "1" 과 "2"로 변경되었다

 

지금은 비록

성능 차이가 눈에 띄지 않을지언정

무거운 데이터를 다루다 보면

분명한 성능 차이를 체감할 것이다

 

굳이 smallint 로 하지 않더라도

필요한 만큼의 char(n) 으로 설정하는 방법도 동일하다

(smallint 는 2 바이트, char(n) 은 n 바이트의 크기를 가짐)

(mysql에는 tinyint라는 1 바이트를 가지는 데이터 타입 존재) 

 

 

이러한 방식으로

DB에는 가볍게 저장만 하고 프론트에서 각각의 항목들을

개발자 의도대로 표출하면 될 것이다

 

환경에 따라 다르겠지만, 만약 전체를 가져오는

로직도 필요할 경우 쿼리문에서 WHERE절을 타는 부분에

조건을 걸어주면 될 것이다

 

더 나아가, 각각 항목들에 대하여

서브 테이블을 만드는 방법도 존재하지만

여기서는 다루지 않겠다