SQL 대형 테이블 디자인

SQL Server 2008 테이블 디자인에 대한 일반적인 질문이 있습니다. 현재 600GB가 넘는 테이블이 있으며 하루에 약 3GB로 증가합니다. 이 테이블에는 적절한 결정이 있지만 쿼리를 실행할 때 크기 때문에 크기가 크게 줄어 듭니다. 문제는 연도 및 월별로 테이블을 여러 테이블로 분할하거나 (다른 부서에서 큰 데이터 세트를 분할하는 방법에 적합 함) SQL Server에 내장 된 파티셔닝을 활용해야하는지입니다. 파티셔닝을 사용하면 적은 코드 변경이 필요합니다. 파티션 할 때 읽은 내용에서 여전히 하나의 테이블을 쿼리하면 서버는 데이터를 얻는 방법을 처리합니다. 다중 테이블 라우트를 수행 한 경우 다중 테이블에서 데이터 가져 오기를 처리해야합니다.

"이 표에는 적절한 결정이 있지만 쿼리를 실행할 때 주요 중단이되고 있습니다"

SQL Server가 쿼리를 실행할 때 파티션을 제거 할 수 없다면 파티션만으로는 쿼리 성능에 도움이되지 않습니다. WHERE 절은 분할 방식과 일치해야합니다. 파티셔닝 필드로 사용할 필드는 하나뿐이므로 해당 필드가 WHERE 절에 포함되지 않은 경우에도 파티션이 있어도 전체 테이블을 스캔 할 가능성이 높습니다.

"그리고 그 크기 때문에."

파티셔닝은 특정 유지 관리 작업을보다 쉽게 ​​해줄 수 있지만 여전히 파티션별로 수행 할 수없는 작업이 있습니다. 인덱스 유지 관리 및 통계 업데이트로 인해 문제가 발생하면 디자인을 보관 테이블과 실시간 업데이트 테이블로 분할하는 것이 좋습니다. 라이브 테이블에서 아카이브 테이블로 데이터를 주기적으로 이동해야하는 경우이를 수행하고 100 % 채우기 비율로 인덱스를 다시 작성하고 전체 스캔으로 통계를 업데이트 한 다음 파일 그룹을 읽기 전용으로 설정하십시오. 파티셔닝은 아카이브 테이블로드에 도움이 될 수 있지만 라이브 테이블 파티셔닝은 그렇지 않을 수 있습니다. (빠르고 간단한 것처럼 몇 가지 고급 개념을 여기에 던지고 있지만 여기서는 배경을 스케치하고 있습니다.)

"파티션을 사용하면 코드 변경이 덜 필요한 것 같습니다."

Sorta kinda-언뜻보기에는 그렇게 보이지만 자세히 들어가면 분할보기와 같은 옵션이 있습니다. 기존 테이블의 이름을 바꾸고 그 자리에 뷰를 놓은 다음 앱을 변경하지 않고도 기본 테이블을 직접 변경하고 여러 테이블을 추가 할 수 있습니다.

분할의 함정에 대해 더 많이 썼습니다.

http://www.brentozar.com/archive/2008/06/sql-server-partitioning-not-the-answer-to-everything/

격리 된 분할은 충분하지만 분할 된 뷰 및 여러 테이블과 결합하여 더 나은 결과를 얻을 수 있습니다. 쿼리 및 성장 패턴에 따라 크게 달라집니다.

분할의 현재 제한 사항은 열 통계가 분할 수준이 아닌 테이블에서만 유지된다는 것입니다. 보다 정확한 통계를 활용하는 쿼리 패턴이있는 경우 테이블 분할을 분할 된 뷰와 결합하면 성능이 크게 향상 될 수 있습니다.

데이터의 특성이 월마다, 해마다 다르면 분할 된 뷰도 도움이 될 수 있습니다. Product line에 일관성이 거의 없도록 제품군을 지속적으로 변경 한 소매 업체를 상상해보십시오. 단일 주문 / 주문 정보 테이블과 단일 통계 히스토그램을 사용하면 통계는 쿼리 최적화 프로그램에 거의 영향을 미치지 않습니다. 월별로 분할되고 분할 된 뷰 (Order, OrderLine)와 결합 된 연간 테이블 (Order_2010, Order_2011, OrderLine_2010, OrderLine_2011)은 옵티 마이저에보다 세분화되고 잠재적으로 유용한 통계를 제공합니다.

비교적 적은 노력으로 테이블 파티셔닝을 도입 할 수 있으므로 시작하여 영향을 측정 한 후 파티션 된 뷰가 추가 노력을 기울일 가치가 있는지 평가하십시오.

킴벌리 트립 (Kimberly Tripp) 은 분할에 관한 많은 지침과 백서를 출판했으며 일반적으로이 주제에 대해 필요한 것으로 간주됩니다. Kendra Little 은 또한 좋은 자료와 다른 기사 의 유용한 참고 목록을 가지고 있습니다.

성능은 일반적으로 사람들이 파티셔닝을 찾는 가장 큰 이유입니다. 개인적으로 복구 시간의 향상은 VLDB의 이점과 동일하거나 더 큰 이점이라고 생각합니다. 시작하기 전에 부분적 가용성 및 단편 복원 을 이해하는 데 시간이 걸리므로 사용 하는 방법에 영향을 줄 수 있습니다.

네트워크를 통해 백업을 전송하는 데 이상적이지 않은 프로세스가있는 경우 현재 600GB에 대해 3 시간의 복원 시간이 표시 될 수 있습니다. 1.5TB를 위반 한 해에 문제가 있습니다.

말했듯이 여기에는 두 가지 옵션이 있습니다.

1. 여러 테이블 활용
2. 파티셔닝 활용

1을 사용하면 해당 테이블을 모두 통합하는 VIEW를 작성하고 새로 작성된 테이블을 포함하도록 업데이트 할 수 있습니다. 나는 이것이 실제로 파티셔닝을 모방하는 방법이라고 생각합니다. 이 방법의 장점에는 Enterprise Edition의 SQL Server가 필요하지 않습니다.

2를 사용하면 인덱스를 파티션에 맞추고 파티션을 다른 스토리지에 맞출 수 있습니다. 파티션 기능과 파티션 구성표를 설정 한 후에는 파티션을 분할하거나 병합 할 때 수행됩니다. 이 방법의 장점에는 레코드를 새 테이블로 수동으로 이동할 필요가 없습니다. 파티션 기능과 파티션 구성표가이를 처리하기 때문입니다. 또한 말했듯이 데이터에 액세스하는 데 코드 변경이 거의 필요하지 않습니다.

Enterprise Edition을 사용하는 경우 파티션을 살펴볼 것입니다. 복잡해 보이지만 실제로 그렇게 나쁘지는 않습니다. 그렇지 않은 경우 파티셔닝은 옵션이 아닙니다.

분할 된 테이블 생성

분할 된 테이블 수정

하위 집합 데이터를 관리하기위한 파티션 설계

도움이 되었기를 바랍니다,

매트

귀하의 질문에 따르면 기록 데이터 (로그)를 저장하는 것으로 보이며 제한은 저장 공간 문제가 아닌 쿼리 속도에서 비롯된 것 같습니다. 나에게 파티션은 도움이되지 않습니다.

적절한 색인이 있다고 말하면 날짜 필드에 색인이 포함됩니까? Postgres에서 trunc (timestamp, day)에 index를 사용하여 좋은 결과를 얻었습니다. 그런 다음 다른 조작을하기 전에 모든 쿼리가 선택되도록해야합니다. 시간대가있는 타임 스탬프 필드는 시간대에 따라 "이동"하기 때문에 인덱싱 할 수 없으므로 인덱싱 할 "고정 된"타임 스탬프가 필요합니다.