로그 테이블 및 통계 테이블 설계 시 고려사항
로그 테이블 설계
설계 시 고려사항
키 컬럼 삭제
로그 및 통계 테이블에는 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