db 트리거에 대해

Question

안녕하세요게시글 테이블 내에 댓글 수, 좋아요 수, 스크랩 수 이렇게 column으로 두고 댓글/좋아요/스크랩 테이블에 해당 게시글 id가 create될 때, 트리거로 해당 column들이 1씩 올라가도록 구성하려 하는데, 트리거가 현업에서 잘 쓰이지 않는다고 하더라구요.그렇다고 해서 해당 column을 없애고 조회할 때마다 count를 하기엔... db가 많이 거대해졌을 때 성능저하가 매우 심각해질 것 같은데, 해당 column은 유지하되 트리거가 아닌 update로 올리나요?보통 어떻게 구성하시나요?

ykd · Answer

write back cache 와 같은 방식을 알아보시면 좋을 것 같아요

ZERO개발자 · Answer

프로시저는 유지보수하기 힘들어서 현업에서 잘 사용안합니다. 그리고 말씀하신 기능은 좋아요, 댓글 같은거 각각 테이블 따로 생성합니다. 좋아요 누르면 좋아요 테이블에 게시물 id,시간, 등록자, 삭제여부 해서 등록해주고 해제하면 삭제여부만 Y로 변경합니다.

3CH-O · Answer

저도 비슷한 고민을 했고, 나름의 대안을 찾았지만 여전히 성능상 이슈가 존재할 것으로 예측돼서 아직도 탐색 중인데요,제가 알아본 바로는 정합성이나 실시간성이 중요하지 않다면 변동수치를 캐싱해두고 주기적으로 일괄업데이트 하거나, 게시글 조회 결과를 캐싱하는 방법이 있었습니다. 모 교육과정의 포트폴리오에서는 락을 걸어서 업데이트 하는 방식을 사용했던데, 거긴 좋아요 하나였지만 글쓴분처럼 스크랩, 좋아요, 댓글 수 등등 컬럼이 많으면 동시성이 심각하게 저하될 것 같아서 기각했구요...비슷한 메커니즘을 갖는 기능으로는 조회수가 있는데 관련 키워드로 찾아보시면 좋을 것 같습니다.

르매 · Answer

트리거는 아무래도 로직이 숨어버리는 현상이 있어서 추천하긴 어렵습니다.대개는 집계 컬럼을 별도로 두고 직접 UPDATE 하는데, 트랜잭션을 걸 것인지 말 것인지는 조금 고민이 필요한 지점입니다. 트랜잭션을 걸자니 딱히 INSERT할 때 &#43;1, DELETE할 때 -1인 작업이.. 부분 실패할 일이 얼마나 있을까 싶기는하죠.만약, SQL Server를 사용한다면 한 가지 대안이 있는데.. Indexed View로 만드는 방법입니다. 댓글의 개수를 반환하는 뷰를 만들고 뷰에 인덱스를 걸면, 이 뷰를 조인해서 개수를 빠르게 가져 올 수 있습니다. 로직이 숨지도 않고 무결성이 깨지지도 않고 성능도 좋아서 이 방법을 많이 사용했습니다.p.s 댓글 중에 프로시저에 대한 얘기가 나왔는데, 프로시저 잘 쓰는 곳을 못 보셨겠죠. 백엔드와 RDB를 한 몸처럼 쓰는 지금의 프레임워크가 제안한 방식이 프로시저 보다 더 낫다고 생각하지 않습니다. ORM 류가 장점이라고 말하는 것들이 사실은 RDB를 별도로 형상 관리하고 리팩토링하고, 벤더 별로 다른 DBMS 의 탁월한 기능을 사용하는 것을 많이 막아 버립니다. ORM이 오래 갈까요? SQL이 오래 갈까요?

장독깨기 · Answer

각 테이블 카운트해서 해보세요.웬만큼 쌓여도 성능저하 별로 없습니다.데이터 직접 쌓아서 한 번 확인해보시구요.간혹 orm 사용하는 분들이 목록 가져오고 루프 돌려서 카운터 세는 쿼리 날리는데요,일케 하면 안됩니다. 한 번의 쿼리로 가져오셔야 합니다.일단 이렇게 해서 완성을 하고 성능을 확인하고 한계치를 확인 해보는 것이 좋습니다.그리고, 대용량 데이터, 트래픽에서 확인을 해보고 싶으시면,제이미터로 트래픽 올려 가면서 직접 병목을 확인하고 개선을 해보는 것이 좋겠습니다.

db 트리거에 대해

5개의 답변

#dbms 목록