SQL Server의 테이블 파티셔닝 접근법

Question

현재 내가 작업하고있는 데이터베이스는 100 GiB 이상이며 내년에 훨씬 커질 것입니다. 내 데이터 집합과 함께 작동하지만 지금까지 비참하게 실패한 파티션 구성표를 디자인하려고합니다. 내 문제는이 데이터베이스에 대한 쿼리는 일반적으로 예측할 수없는 방식으로 겹치는 결과 집합에서 끝나는이 큰 테이블의 여러 열의 값을 테스트합니다.

누구나 (내가 작업하고있는 DBA)는 특정 크기 이상의 테이블을 가지고 있다고 경고하고 내가 만났던 솔루션을 조사하고 평가했지만 모두 논리적 인 데이터 특성에 의존하는 것처럼 보입니다 테이블 파티셔닝. 불행히도, 나는 테이블의 구조가 주어진다면 그것을 달성 할 수있는 방법이 보이지 않습니다.

여기 두 개의 주 테이블 구조가 있습니다. 위의 열 중 쿼리 매개 변수로 사용될 수 있음을

Table: Case 
Columns: 
Year 
Type 
Status 
UniqueIdentifier 
PrimaryKey 
etc. 

Table: Case_Participant 
Columns: 
Case.PrimaryKey 
LastName 
FirstName 
SSN 
DLN 
OtherUniqueIdentifiers 

참고.

Answer 1

측정보다 측정하십시오. 사용 통계 (queries run)를 수집하고 sys.dm_db_index_usage_stats과 같은 엔진 자체 통계를 살펴본 다음 정보를 바탕으로 결정합니다. 데이터 크기의 균형을 유지하고 가장 자주 실행되는 쿼리에 가장 적합한 선호도를 제공하는 파티션이 좋은 후보가됩니다. 물론 당신은 타협해야 할 것입니다.

또한 partitioning은 테이블 당이 아닌 인덱스 ('테이블'= 하나의 인덱스 중 하나임)이기 때문에 질문은 어떤 파티션이 아니지만 어떤 인덱스가 파티션인지 여부와 어떤 파티셔닝인지 사용하는 기능. 두 테이블의 클러스터 된 인덱스가 분명히 가장 가능성있는 후보가 될 것입니다. 클러스터되지 않은 인덱스 만 분할하고 클러스터 된 인덱스는 분할하지 않는 것이 좋습니다. 클러스터 된 키의 재 설계를 고려하지 않는 한, 실제로 클러스터 된 인덱스에 대해 선택할 수있는 분할 함수입니다.

시간이 지남에 따라 축적되는 데이터 (예 : '연도'와 같이 '연도')가 가장 자연스러운 파티션은 sliding window입니다.

Answer 2

다른 선택이 없다면 키 모듈별로 파티션 테이블의 수를 나눌 수 있습니다. 10 개의 테이블로 분할하려고합니다. 당신은 테이블 정의합니다 :
Case00
Case01
...
Case09

를 그리고 고유 식별자 또는 기본 키 모듈 (10)에 의해 당신에게 데이터를 분할하고 해당 테이블의 각 레코드를 배치 (고유 고유 식별자 당신에 따라 ID의 수동 할당을 시작해야 할 수도 있음).

쿼리를 수행 할 때 모든 테이블에서 동일한 쿼리를 실행하고 UNION을 사용하여 결과 집합을 단일 쿼리 결과로 병합해야합니다.

예상 검색어에 해당하는 논리적 인 분리를 기준으로 테이블을 분할하는 것만 큼 좋지 않지만 테이블의 크기 제한을 초과하는 것이 좋습니다.

Answer 3

(파티션하기 전에) 또 다른 가능한 것은 귀하의 모델입니다.

정규화 된 데이터베이스에 있습니까? 정규화/디 -/부분 정규화에서 다양한 선택에 따라 성능을 향상시킬 수있는 추가 단계가 있습니까?보고/쿼리에 최적 인 Kimball 스타일의 차원 별 모델로 데이터를 변환하는 옵션이 있습니까?

테이블의 파티션을 삭제하거나 (슬라이딩 윈도우, 언급 한 바와 같이) 또는 다른 파티션을 다르게 처리하지 않을 경우 (어떤 컬럼이든 쿼리에 사용될 수 있다고 말하면), 나는 당신이 무엇을 시도하는지 확신하지 못합니다 인덱싱 전략에서 벗어나지 못하도록하는 파티셔닝에서 벗어나십시오.

행에 대한 테이블 제한을 알지 못합니다. AFAIK, 행 수는 사용 가능한 저장 공간에 의해서만 제한됩니다.