로그 테이블 및 통계 테이블 설계 시 고려사항

로그 테이블 설계

설계 시 고려사항

키 컬럼 삭제
로그 및 통계 테이블에는 CRUD 중 생성, 읽기만 일어나기 때문에 PK가 필요 없습니다.
키 컬럼이 있으면 저장공간을 더 차지하기만 해서 좋지 않습니다.

인덱스 생성 지양
select에 비해 insert가 더 자주 일어나는 테이블에는 인덱스를 걸지 않는 것이 좋습니다.

콘텐츠 조회 로그 테이블 예시

제약조건 컬럼명 데이터 타입 기본값 설명
content_id INT 콘텐츠ID
service_id INT 서비스ID
hit_date DATETIME NOW() 조회일시
hit_user_id INT 조회유저ID

로그 테이블 조회 시 고려사항

사용자가 로그 조회 지양
관리자 화면에서 대용량 로그를 조회하는 것은 DB 서버에 부하를 줘서 성능 이슈가 발생할 수 있습니다.
매일 스케줄러로 로그 테이블을 집계하고 일별 통계 테이블을 조회하는 것이 좋습니다.
배치는 사용자가 적은 시간에 자동 실행되게 설정할 수 있습니다.

파티셔닝 사용 고려
데이터가 커진 테이블을 여러 파티션으로 나누어 저장하면 조회 성능을 향상시킬 수 있습니다.
특히, 시간 기반의 파티셔닝은 로그와 같은 시계열 데이터에 유용합니다.

날짜 조건으로 로그 조회 지양
대량의 로그 테이블을 날짜 조건으로 검색하려고 날짜 컬럼에 인덱스를 걸면, 인덱스 건 것 때문에 insert 시 오버헤드(간접적인 처리 시간)가 발생할 수 있습니다.

로그 테이블 조인 지양
로그 테이블 사이즈가 커지면 조인 작업이 오래 걸리기 때문에,
메인 테이블 조회로 기본 정보를 가져오고 로그 테이블은 ajax로 조회하는 것이 좋습니다.


통계 테이블 설계

설계 시 고려사항

범위가 크고 경우의 수가 많은 컬럼을 상위에 배치해야 합니다.

콘텐츠 이용 통계 테이블 예시

제약조건 컬럼명 데이터 타입 기본값 설명
use_date DATE NOW() 콘텐츠이용일
content_id INT 콘텐츠ID
service_id INT 서비스ID
hit_cnt INT 0 조회수
download_cnt INT 0 다운로드수
good_cnt INT 0 좋아요수

검색어 통계 테이블 예시

제약조건 컬럼명 데이터 타입 기본값 설명
search_date DATE NOW() 검색일
keyword VARCHAR 검색어
service_id INT 서비스ID
hit_cnt INT 0 검색수

다중 컬럼 인덱싱 방법 2가지
1) 복합키 걸기 (검색일, 검색어, 서비스ID)
2) PK 걸지 않고 각각 개별 인덱스 걸기
검색어 통계 테이블에서는 후자를 선택하였습니다.

Leave a comment