이번 프로젝트에서 가장 핵심이 되는 엔티티 중 하나인 “맛집”은 굉장히 많은 속성을 가지고 있습니다.
경도, 위도 등의 필수적인 정보부터 남자 종업원 수, 영업장 주변 구분명 등 잘 사용되지 않는 속성들을 모두 합하면 총 24가지의 속성을 가지고 있습니다.
이 속성들을 모두 한 테이블에 담아도 동작에 문제는 없겠지만, 조회 시에는 성능이 떨어질 수 있습니다.
보통 생성, 수정, 삭제, 조회 중 가장 많이 쓰이는 것이 조회이기 때문에, 가장 성능을 신경 써야 하는 것도 조회입니다.
따라서 엔티티의 속성을 종류별로 나누어서 1:1 관계를 맺는 별개의 테이블로 관리하는 것이 좋다고 생각합니다.
별개의 테이블을 어떻게 나누는 것이 좋을지 고민을 한 결과, 다음과 같은 후보들이 떠올랐습니다.
비슷한 성질을 가지는 종류별로 나눈다.
예를 들어 위도, 경도는 맛집 위치 테이블에 저장하고, 위생 관련 정보들은 맛집 위생 테이블에 저장합니다.
분리되는 테이블의 수는 많겠지만, 조회를 할때는 주로 사용되는 테이블만 호출하면 되기에 성능에 유리합니다.
또한 다음에 설명할 2번 방법보다 더 세부적으로 테이블을 나누었기 때문에 속성 자체의 추가 및 삭제에 용이합니다.
단, 1개의 맛집 정보를 관리할 때, 쿼리문이 테이블을 나눈 개수만큼 배가 되어 나가기 때문에 주의가 필요합니다.
주로 쓰이는 속성 / 그렇지 않은 속성으로 나눈다.
1번 방법보다 조회 성능을 더 극한으로 나눈 방법입니다.
조회를 할 때, 주로 쓰이는 속성 테이블만 호출하면 되므로 쿼리문을 여러번 날리지 않아도 됩니다.
테이블을 나눈 개수가 1번 방법보다 적기 때문에 생성 및 삭제 시에도 비교적 성능이 좋습니다.
하지만 단순히 속성의 사용 빈도로 테이블을 나누었기 때문에 이후 속성의 사용 빈도가 변화한다면 테이블 자체에 변화가 필요합니다.
하나의 테이블에 모든 속성을 넣는다.
이 방법은 생성, 삭제 등에는 쿼리문을 1번만 보내면 되기 때문에 훌륭한 성능을 보일 것 입니다.
하지만 앞서 말했듯, 성능에 있어서 가장 중요한 것은 조회이며 조회의 성능을 굉장히 떨어뜨릴 수 있습니다.
따라서 많은 데이터의 조회가 요구되는 상황에서는 지양해야하는 방법이라고 생각합니다.
저희 팀은 1번 방법을 선택해서 비슷한 속성끼리 묶어서 테이블을 생성했습니다.
데이터 갱신을 위해 총 50000개 가량의 맛집 데이터를 생성해야 해서 결과적으로 작업은 50000 * 8 = 40만번 가량이 일어납니다.
하지만 맛집 데이터의 갱신은 스케쥴러를 통해 주 1회 새벽 시간에만 이루어지도록 설계했습니다.
따라서 새벽 시간에 5분 이하로 걸리는 생성을 최적화하자고 가장 많이 요청될 조회의 성능을 떨어뜨리는 3번 방법을 택하지 않았습니다.
또한 이 후의 유지보수 확장성을 생각하여 2번 방법보다는 테이블을 세분화하는 1번 방법이 더 적합하다고 판단했습니다.