SQL Server 파티션 작업을 한 적이 없지만 현재 볼륨이 보증하는 데이터베이스를 설계하는 데 직면했습니다. 이 시스템은 쿠폰 용입니다. 쿠폰은 정기적으로 발행되며, 일반적으로 6 주마다 발행됩니다 (예 : 특별 행사 등). 1,500 만 명의 고객이 있으며 각 발행 이벤트마다 6 개의 서로 다른 쿠폰 유형이 제공되므로 총 9 천만 개의 쿠폰 인스턴스가 제공됩니다. 쿠폰 인스턴스 상환 데이터를 추적하고이를 6 개월 동안 유지해야하지만 일반적으로 쿠폰은 6 주 동안 만 유효합니다. 유효하지 않은 쿠폰에 대한 상환 요청은 POS까지 확인되므로 데이터베이스에 도달하지 않습니다.
6 개월 동안 쿠폰 인스턴스 테이블에 3 억 6 천만 개의 행을 저장하고 구속 테이블에 최대 2 억 7 천만 (최대 20 %의 상환율을 가정)을 저장해야합니다. 이 숫자가 단일 파티션에 비해 너무 크다는 느낌이 듭니까?
내 질문은-파티션 키로 무엇을 사용해야합니까? 명백한 후보 중 하나는 발행 이벤트에 의한 것으로 약 6 개의 파티션을 제공합니다. 그렇다면 파티션 크기가 너무 커서 최적의 성능을 발휘할 수 없을 것이라고 생각합니다. 발급 이벤트 + 고객 ID의 마지막 숫자와 같이 두 개의 키로 분할 할 수 있습니까? 따라서 논리는 다음과 같습니다.
If issuance event = 1 and last digit of customer id < 5 then
Store in partition 1
Else if issuance event = 1 and last digit of customer id >4 then
Store in partition 2
Else if issuance event =2 and last digit of customer id <5 then
Store in partition 3
Else if issuance event =2 and last digit of customer id >4 then
Store in partition 4
Etc...
또한 필요한 데이터베이스 서버의 사양을 잘 모르겠습니다. 16GB 및 8CPU면 충분합니까? db는 0.5 초 이내에 숫자 바코드 값을 사용하여 쿠폰 인스턴스 테이블의 결과를 반환 할 수 있어야합니다. 유효성 검사 (선택) 및 교환 (삽입)에 대한 예상 트랜잭션 요청은 분당 약 3,500 개로 정점에 도달 할 것으로 예상됩니다.
SQL Server 2008r2 64 비트 db 서버는 고성능 및 대용량 SAN에 액세스 할 수있는 매우 강력한 호스트에서 VM으로 제공됩니다.
비슷한 볼륨을 관리하기 위해 SQL Server 솔루션을 배포 한 사람들의 조언에 매우 감사드립니다.
문안 인사
롭