2025.04.29 좋아요 정렬

 

 

 

 

Case 1

'좋아요'를 구현할 때 어찌해야 하는가를 다루고 있습니다.

 

정렬을 제외했을 때는..

데이터가 많지 않다면 post_like 매핑 테이블을 만들어서 group by sum을 통해서 값을 얻을 수 있습니다.

데이터가 많아지면 버퍼에 없을 가능성이 커지므로 디스크 IO가 증가하게 될 것입니다.

또 group by이기 때문에 임시 테이블을 사용하게 되고, 데이터가 많으면 디스크 스필이 이뤄지게 되고 더 느려지게 됩니다.

그럼 그때 성능 최적화를 하면 됩니다.

 

Case 2

성능 최적화 방법으로는 뭐가 있을까요?

음..

캐시 생각하기 전에 게시물당 좋아요를 카운팅 하는 테이블을 둡시다.

게시글에 칼럼에 카운팅을 두지 않으므로서 게시물의 데이터 경합에서 벗어날 수 있습니다. 

좋아요 카운팅 경합이 더 많겠지요?

 post_meta 테이블을 만들어 이번엔 post당 하나의 로우로 카운팅을 모아봅시다.

그럼 groub by가 아닌 단순 조회 혹은 join이기 때문에 디스크 스필이 이뤄지지 않을 겁니다. 디스크 IO가 증가는 DB 로우에 따라 다름. 

그럼 속도는 해결됩니다.

메타 테이블로 뽑음으로써 정렬도 해결되겠네요. 

영상에서 또 말하는 것은.. 그럼 post_meta 테이블에 insert, update시 경합이 발생하게 되는데, (로우가 하나이니) 이걸 최종 일관성으로 처리할 수 있다는 것입니다.

이벤트 발행을 해서 좋아요의 경합을 줄이는 것이지요. update 경합은 줄 것이고, mvcc 환경이라면 update로 x lock을 잡아도 읽을 수 있으니 성능상의 문제도 해결될 것입니다,