안녕하세요..
다름이 아니고 제가 로그를 기록하기위한 용도로 테이블을 쓰는데요..
들어가는 필드는..
USER_ID, POINT, CREATEDATE
이렇게 유저아이디, 점수, 날짜로 들어갑니다.
로그테이블은 평소에는 사용자액션에 따라서 INSERT만 하는 용도인데요..
데이터가 쌓이면 관리툴에서 조건에 따라 검색하는 용도로도 사용할려고 합니다.
예를들어서 툴에서 USER_ID로 검색해서 본다던지, 날짜별로 보여준다던지...
그런데.. 데이터가 100만건 1000만건 쌓이면 인덱스를 걸지않고는 관리툴에서 USER_ID로
검색을 할때 결과가 상당히 느려질것 같아서요..
이리저리 찾아보니 로그테이블에는 왠만하면 인덱스를 걸지말라고 하더군요..
만약에 위와같은 조건에서는 어떻게 해야하는지 알려주시면 감사하겠습니다. ^^
그리고, 또한가지 궁금한점은 만약에 인덱스를 건다고 하면..
로그테이블처럼 평소에 INSERT만 하는 조건이면
클러스터인덱스와 넌클러스터인덱스 둘중 어떤것이 부하가 적게 걸리는지요?
그리고 USER_ID, POINT CREATEDATE 필드 어디에 어떤식으로 인덱스를
걸어야하는지도 알려주시면 감사하겠습니다.
초보라서 쉽고 상세히 가르쳐주시면 감사하겠습니다. ^^
Comment 5
-
History
2013.04.28 16:08
-
카즈야마(이정우)
2013.04.29 11:57
안녕하세요.
로그테이블같은 서비스 영역의 대용량 테이블이라고 가정해보시는 것도 좋은 방법일듯 싶습니다.
로그성이라 기간이 지나면 지날수록 대용량 테이블이 될 우려가 있는데
이럴때 보편적으로 테이블 물리적으로 구분하는 파티셔닝을 하던지
파티셔닝 테이블을 사용할 듯 싶은데요.
제 개인적인 생각으로는 문의하신 내용으로만 봐서는 파티셔닝 걸고 검색 조건을 좀 더 추가 하시면 (특정 기간 정도)
인덱스를 거셔도 크게 문제는 없을 듯 합니다.
좀 더 자세한건 일단위 누적량 및 update 유무, 조회 빈도 수 데이터 분포도정도도 같이 올려주시면
고수님들께서 좋은 방안 알려주실겁니다^^
-
무념
2013.04.29 16:20
위의 의견에 제 생각을 추가한다면, 로그 테이블은 로그 테이블입니다. 참고하기 위한 데이터이지
계속 조회하고자 사용한다면 애초에 분석 및 설계가 잘못됬다고 생각합니다.
용도에 따라 일정기간이 지나면 삭제할 수 도 있겠고요.
분석 및 설계에서 로그 테이블의 사용 용도는 근거 데이터 이상으로 사용하자고 한다면 좀 문제가 있다고 생각하는
편입니다.
기획에서 나온 차후에 내가 필요한 데이터는 뭔지와 확장성을 고려하여
일정 기간 주기로 기획단에서 필요로하는 데이터를 추출하여 키값을 주어 기록하여
그 테이블을 조회하는게 답인 것 같습니다.
어쩔 수 없이 로그테이블을 자주 조회해야 한다면 인덱스를 주는게 답일 것 같습니다.
-
don12345
2013.04.30 17:38
여러의견 감사드립니다. ^^
근데.. 하루에 100만건정도 쌓인다면 인덱스를 안걸어야 겠죠? ㅡ,.ㅡ
일단 로그테이블은 유저단에서는 select가 안되는 부분이니
인덱스를 안거는 방향으로 해야겠네요. 인덱스 건 상황에서 데이터가 많이 쌓여버리면
cpu나 i/o에 부담이 많이 될것 같아서요.. 정기적으로 로그를 삭제하는 정책을 만들어서
관리단에서 select할때 부담을 좀 줄이는 방향으로 해야겠네요
-
minsouk
2013.05.01 05:17
데이터와 조회쿼리를 봐야 하지만 조회가 있다면 인덱스는 겁니다
로그 테이블이건 데이터 테이블이건 전부 데이터가 들어있는 테이블입니다.
또한 해당 데이터가 들어있는 테이블을 어떤 방식으로 사용하냐에 따라서 인덱스를 설정해야겠지여
만약 로그 테이블의 selct 를 1년에 한번정도 하고 속도도 상관없다면 설정을 안하는편이 좋겠지만
적어도 월별 등등 의 기간으로 주기적올 데이터를 추출한다면 설정하느것이 옳다고 생각됩니다.