별도의 집계 테이블을 생성할 때 고려해야할 점이 무엇인가요?

Question

현재 한 사용자가 한 샵에 대해서 특정 주문을 몇번했는지 조회하는 기능이 있습니다. 주문마다 사용자 정보란에 함께 보여지므로 조회가 자주 이루어지는데요, 기존에는 주문 테이블의 모든 튜플을 조회하고 shopid userid 주문유형을 확인해서 특정 주문을 몇번했는지 확인하는 방식으로 구현을 했습니다. 근데 주문 테이블은 계속해서 커지고 이렇게 자주 조회가 이루어지는데 그때마다 풀스캔을하면 성능이 떨어질 거 같아서 이런 값을 저장해두는 집계용 테이블을 만드는 게 좋다고 생각해서 구현 중에 있습니다. 해당 테이블은 다음과 같은 필드를 갖는데요,user_id | shop_id | reservation_count | pickup_count | no_show_count user_id, shop_id를 복합키로 갖고 있습니다. 현재 구현 상으로는 특정 주문이 이루어질 떄 정상적으로 주문이 끝까지 완료될 때 이 테이블의 필드값을 증가시키고, 주문해놓고 고객이 노쇼를해서 상태가 노쇼로 바뀌는 시점에 테이블의 no_show_count필드를 증가시키고 있습니다. 이 데이터 자체가 정확성이 중요한 부분도 아니고 같은 사용자가 특정 샵에 한번에 주문을 하는 경우도 없을테니, 같은 튜플을 동시에 수정하려는 동시성 문제도 고려할 필요가 없다고 생각해서 이외의 별다른 구현은 하지 않았습니다.혹시 제 구현 방식에 대해 고려해볼만한 부분이 있을까요? 조언해주시면 감사하겠습니다.

RH.BY · Answer

테이블에 클러스터 인덱스 설정, 필요한 데이터만 추출해서 View화, 불필요한 조회조건/Join 삭제이 정도로 생각이 드는데.. 어떤가요?

yeori · Answer

풀스캔을하면 성능이 떨어질 거 같아서진짜로 성능이 떨어지는지부터 확인해보는게 좋을듯합니다.

장독깨기 · Answer

풀 스캔 아니구요, 회원아이디, 상점 아이디로 인덱스 타잖아요.데이터 넣고 확인 한 번 해보세요. :)근데, &#34;기존에는 주문 테이블의 모든 튜플을 조회하고&#34; 이게 무슨 말일까요.where user_id &#61; ? and shop_id &#61; ? 이런 식으로 한게 아닌가요?

Devvy · Answer

데이터베이스에 저장하기 전 앞단에 캐시를 사용하는건 어떨까요? In-memory에 카운터를 관리하므로 속도도 빨라질뿐더러 redis에 저장된 카운터를 주기적으로 db에 플러시함으로써 데이터 유실을 방지할 수 있습니다.만약 counter의 수가 기하급수적으로 커진다 가정했을 때 redis에는 hyperloglog라는 자료구조를 사용할수도 있습니다. Hyperloglog는 unique한 데이터의 갯수에 대한 예상값을 저장할 수 있습니다. 확률형 자료구조이기 때문에 정확도가 높지는 않지만(정확도가 높지 않은 이유는 성능을 끌어올리기 위해서입니다) 글쓴이 분의 요구사항에는 적합할 것 같습니다.

별도의 집계 테이블을 생성할 때 고려해야할 점이 무엇인가요?

4개의 답변

#aggregation 목록