안녕하세요. 대용량 테이블 질문드립니다
외부 DB 여러곳 에서 데이터를 매일 가져와서
하나의 테이블에 약 5천만건 정도의 데이터를 유지하려고 합니다.
4가지 정도 조건의 인덱스들이 생성되어 있구요.
단순한 로그성 테이블은 아니고 조회도 해야됩니다. 조회 사용자는 관리자용이라 많지는 않고요.
5천만건 정도 쌓여있는 상태에서 배치로 매일 약 1~2프로의 데이터를 insert 하고 또 그 정도 만큼 삭제하려고 하는데요.
대용량 테이블의 경우 파티션 테이블을 사용해야되는 것으로 알고 있는데
스탠다드 버젼의 경우 파티션 테이블을 제공하지 않는다고 들었습니다.
MSSQL도 익숙하지 않을 뿐더러 DBA의 도움없이 혼자서 테이블 설계를 해야되는데 대용량 테이블을 어떻게 해야할 지 모르겠습니다.
파티션테이블 없이 위 내용의 작업을 무리없이 수행할 수 있을까요?
일 배치 수행시간은 1~2시간 내외로 목표를 잡고있습니다.
질문 요약하자면 아래와 같습니다.
1. 위와 같은 상황에서 약 1~2프로정도에 해당하는 양의 데이터를 insert, delete 할건데 문제가 없을지
2. 파티션테이블 없이 대용량 테이블 설계시 중점적으로 봐야할 부분
3. 만약 불가능 하다면 어떤식으로 처리하는게 좋을지
그 외 전체적으로 어떤방식으로 처리해야 좋을 지, 잠재적인 문제점은 없는지 고수님들의 조언 부탁드립니다.
환경은 sql 서버 2008 스탠다드입니다.
Comment 3
-
catchv
2013.12.10 11:19
-
열이
2013.12.10 16:31
* 가능하면 컬럼사이즈 적게 설계 (ex: 일괄 int -> int, smallint, tinyint 등 세분화)
* database mdf, ldf 사이즈는 자동증가가 일어나지 않게 넉넉하게 미리 설정
* database recovery model 을 simple 로 변경 가능한지 검토
* T610 추척플래그 사용여부 검토 ( 트랜잭션 로그 최소로깅 -- 단순,대량 복구모델만 영향 )
* insert 할 데이타를 여러군데에서 직접 여러번 받아 넣는것보다
중간 별도 staging DB 에 일단 다 담은뒤 한꺼번에 insert 하는 방법 검토* insert 시 최소로깅 조건 고려 - 구문에 WITH(TABLOCK) 추가
http://msdn.microsoft.com/ko-KR/library/ms190422.aspx* delete 시 삭제할 데이타 선택의 최적화 하기 -> 삭제할 데이타 찾는 키에 clustered index 검토
* 삭제할 양이 그래도 많다면 while 문으로 트랜잭션 부하 줄여서 삭제하기 검토
WHILE(1>0)
BEGIN
DELETE TOP (1000) FROM dbo.TableSample
WHERE REASON ='this is delete'
AND DELTIME < (getdate() - 5 )
IF @@ROWCOUNT = 0 BREAK
END
* 수동 파티션 구현 검토 : 스케쥴에 의한 일별,월별,년별 테이블 생성, 데이타 이관, 삭제 관리
---------------------------------------------------------------------------------------------------------------
이정도 전략을 고려해 보시면 충분할 것 같습니다.
-
sams
2013.12.10 16:52
정말 원하던 답변을 딱 주셔서 감사합니다.
말씀해주신 내용 토대로 수행해보겠습니다^^
도움이 될지 모르겠지만 경험을 이야기 드리자면 계속 누적되는 데이터(마지막에 본건이 15억 정도)가 있었습니다.
DELETE(당일 데이터 가능) 는 없었고 SELECT, INSERT,UPDATE 는 있었습니다. 하루 변경되는 건수는 20만건 정도 였습니다.
파티션 구성은 안되는 상황이였습니다. 년도 마다 테이블 생성하였습니다. Table_2013, Table_2014...(년 말에 쯤에 생성하였습니다.)
들어오는 신규 및 업데이트 데이터에 대해서 년도별로 생성된 테이블(뷰를 만들어서 뷰에 조회)에서 조회를 하여 데이터를 검증하고 특정 테이블에 저장을 하고 새벽에 배치 작업으로 동적 쿼리를 이용해서 실제 년도별 테이블에 저장하는 방법을 사용하였습니다.
여기는 새벽에 작업이 없는 업무라서 이런 식으로 구현을 한적이 있습니다.
디스크도 여유가 있어서 LOG size 걱정은 크게 하지 않았습니다.(중요 데이터라서 로그백업 풀백업 모두 하였습니다.)
보통 디스크 공간이 없으면 Log Size가 문제 되는 경우도 많이 있으니깐 참고하시기 바랍니다.