Join 연산 무조건 피해야 하나?

프로젝트 진행 중 불필요한 연관관계를 끊고, 조회 성능을 향상시키기 위해 Post 테이블에 member 정보에 대한 컬럼을 추가했었다.

 

컬럼을 추가할 생각을 가졌을 때에는 당장 연관관계보다의 장점만을 생각하면서 진행하였지만 막상 적용하고 나서 보니 단점도 보이기에 이 글을 적게되었다.

 

단점으로는 데이터 일관성이 있겠다.

닉네임이 member_A 인 회원이 글을 작성하면 해당 post의 작성자 닉네임은 당연하게도 member_A 이다.

하지만 이후 member_A가 닉네임을 member_B로 수정을 한 후에도 이전 post의 작성자 닉네임은 member_A 이다.

여기까지는 예상을 했던 상황이고 그저 post 수정 시 새로 업데이트 해주면 되겠다 생각을 했다.

하지만 또 다른 회원이 member_A로 닉네임을 수정했을 때이다. 이런 경우 member_A 회원은 자신이 쓴적 없는 post를 보게 되는 것이다. 물론 member_id가 다르기 때문에 주체가 바뀌는 것은 아니지만 Ori 서비스는 기본적으로 닉네임을 유니크 설정해놨기에 이 상황은 마냥 달갑지 않은 것이다.

 

그렇기 때문에 post의 컬럼으로 member_id, member_nickname, member_email을 갖고 있는 상황에서 member_id를 제외하고는 삭제한 뒤에 member_id로 Join을 하는 방식을 생각했다.

그렇다면 Join 이 포함된 쿼리로 했을 때 조회 시간이 얼마나 차이가 나나 테스트해보고 성능 상 큰 차이가 없다면 적용할 생각이다.

---

code_post 100개 정도로 테스트를 진행해보았다.

아래의 테스트 결과는 로컬 환경에서 기존에 post 전체 조회 결과이다.

수정 전 응답 속도

90% 가 418.04ms의 응답 시간을 보이고, 95% 가 463.19ms 의 응답 시간을 보이고 있다.

 

수정 후 응답 속도

 

...?

inner join의 응답 속도가 더 빠르게 나왔다. 몇번을 시도해보고 데이터도 2000개로 늘려서 해봤는데도..

여러번의 검색을 통해 알게된 정보로는 임의로 데이터를 삽입해서 inner join을 진행할 경우 데이터 삽입 패턴이 inner join에 유리하게끔 저장이 되있을 경우라던가 여러 복합적인 이유를 통해 더 빠른 계산 결과가 나올 수 있다고 한다..

---

2025-03-28

이전 결과는 code_post 데이터를 너무 순차적으로 데이터를 집어넣었다 생각해서 inner join에 유리한 환경이 될 수 있다는 생각에 이번에는 랜덤하게 2000개의 데이터를 넣고 시도해보겠다.

수정 전 응답 속도

수정 후 응답 속도

 

데이터를 랜덤하게 삽입한 후 테스트 해보니 예상했던 대로 단순 Select 조회 속도가 Inner Join 속도보다 빠른 것을 확인하게 되었다. 

이 결과를 토대로 성능은 18.3% 정도 감소되었지만 애초에 단순 Select 로 해결될 수 없는 상황이기 때문에 성능감소라는 말 자체가 맞지 않다고 생각했고, member에 대한 데이터 일관성을 지키기 위해 inner join 방식을 채택하기로 했다.

---

Left Join 말고 Inner Join을 쓴 이유

아래 결과는 Left Join을 사용한 API 응답 결과이다.

결과에서 보이다 싶히 inner join에 비해 성능적으로 떨어지는 것을 볼 수 있다.

 

성능차이가 발생하는 이유는 

INNER JOIN:

두 테이블 간의 공통된 데이터만 반환된다.

즉, 두 테이블 모두에서 일치하는 레코드만 포함된다.

LEFT JOIN (또는 LEFT OUTER JOIN): 

왼쪽 테이블의 모든 데이터를 반환하고, 오른쪽 테이블에서 일치하는 데이터가 없으면 NULL로 채워서 반환한다.

즉, 왼쪽 테이블의 모든 레코드가 포함된다.

 

이러한 이유로 성능적 차이가 있기도 하고, code_post는 작성자에 대한 정보가 무조건 존재해야하기 때문에 inner join을 택하게 되었다.