질문하나만 드릴께요. 데이터가 천만건이상 들어온다고 가정하고 설계를 하고 싶은데요.(잘되서 많은 사람이 사용한다고 가정, 1달에 100만건 가정)
키설정을 (사람키, 등록일시(datetime)) 게 잡으면, 키생성에서 드물게작성하는 중복키문제도 해결될것같고, 게시물에대한 인공키를 생성하지 않는 장점도 있는거 같습니다.
쇼셜네트워크이다보니 관련된 사람의 데이터를 조회하는 경우가 많을것같은데 사람이 키이다보니 새로운 인덱스를 생성하지 않아도되는 장점도 있는거같네요.
질문1. (사람키[1번], 등록일시(datetime)[2번])로 생성시 데이터가 인서트될때 느리지 않을까요? 혹시나 사람키에대한 저장공간이 다차서 저장공간이 이동되거나, 인덱스를 다시 잡는경우가 발생하는지 여쭙고 싶어요.
질문2. 혹시나 너무많은 데이터가 들어온다고 가정하고, 테이블을 파티셔닝(테이블명1개, 물리적공간 n개)한다고 하면 사람별로 하는게 좋을까요? 등록일시(datetime)에 해당하는 6자리 년월을 따로 컬럼(year_month)을 두어서 year_month기준으로 파티셔닝을 하는게 좋을까요? 아니면 파티셔닝을 아에 안하는게 좋을까요?(조회는 항상 1달단위로 처리)
현재생각으로는 6자리 년월을 파티셔닝을 하고 (사람키[1번], 등록일시(datetime)[2번])으로 잡는게 좋다고 생각이 됩니다.
처리루틴 : 일반저장소(저장 및 year_month 생성) -> 트리거(데이터복사) -> 실제저장소(파티셔닝 되어있는) 이런방식을 생각하고 있습니다.
끝까지 읽어주셔서 감사합니다.
좋은 조언좀 부탁들입니다.
Comment 1
-
자리비움
2017.08.18 16:44
1.사람 키(사람키,등록일시)가 저장공간(page)이 다 차면 저장공간이 이동(split)해요.(split 이슈를 줄이기 위해 fillfactor, pad pad_index 등을 설정하기도 해요.)그리고, 여러 이유(split, 통계 업데이트 등)로 인덱스를 다시 잡아요.위 업무는 db 점검이 가능한 업무 환경이고요.2.한 테이블에 수억, 수십억 건도 인덱스가 잘(?) 걸려 있고, 쿼리 잘 짜면 문제 없어요.한달에 천만건씩 쌓여도 쌓는건 문제가 없고요. 초당 수만건씩 몰리지만 않으면요.파티셔닝을 고려하시는게 단순히 데이터량 기준으로만 잡으신 것 같아서 말씀 드렸고요.참고로, 날짜로 파티셔닝을 하신다면 (조회는 항상 1달 단위로 처리) 라고 하셨는데대부분의 상황에서 아마 1개 테이블(최신 1개월)만 바쁠 것 같기도 하네요.부하 분산 목적에서 어떤 형태로 하실지 다시 검토해보시면 좋을 것 같아요.처리루틴도 코딩으로 파티셔닝을 구현하시려는걸로 보이는데 다른 더 좋은 방법들이 있을 것 같구요.적어주신 내용만을 기준으로 해야한다, 안해도 된다라고 답변을 드리기가 좀 애매해서여기까지만 적겠습니다.
