SQL Server 데이터 압축은 읽기 전용 데이터베이스에 범주 적으로 적합합니까?

내가 읽은 SQL Server 데이터 압축에 대한 일부 문헌은 쓰기 비용이 일반적으로 필요한 것의 약 4 배로 증가한다고 말합니다. 또한 이것이 데이터 압축의 주요 단점임을 암시하는 것으로 보이며, 읽기 전용 아카이브 데이터베이스의 경우 100 % 채워진 페이지의 데이터 압축을 사용하면 성능이 향상 될 것입니다 (예외가 거의 없음).

1. 위의 진술이 사실입니까?

2. 데이터 압축과 그렇지 않은 것 사이의 주요 "변이"는 무엇입니까 (읽기)

   • "CPU + x %"?
   • "IO -y %"?
   • 페이지 분할 발생?
   • tempdb 사용법?
   • RAM 사용량?
3. 그리고 글을 위해?

이 질문의 목적으로, 컨텍스트를 큰 (> 1TB) 데이터베이스 의 PAGE 수준 압축으로 제한 할 수 있지만 추가 의견은 언제나 환영합니다.

참고 문헌 :

SQL Server 스토리지 엔진 블로그 (DW 시나리오는 압축이 매우 유리함을 보여줍니다)
데이터 압축 : 전략, 용량 계획 및 모범 사례

압축 대상을 결정하는보다 자세한 방법은 각 테이블 및 인덱스의 워크로드 특성을 분석하는 것입니다. 다음 두 가지 메트릭을 기반으로합니다.

U : 특정 테이블, 인덱스 또는 파티션에서 해당 개체의 전체 작업에 대한 업데이트 작업의 백분율입니다. U 값이 낮을수록 (즉, 테이블, 인덱스 또는 파티션이 자주 업데이트되지 않음) 페이지 압축 후보가 더 좋습니다.
S : 테이블, 인덱스 또는 파티션에서 해당 개체의 전체 작업에 대한 스캔 작업의 백분율입니다. S 값이 높을수록 (즉, 테이블, 인덱스 또는 파티션이 대부분 스캔 됨) 페이지 압축 후보가 더 좋습니다.

위의 두 가지 모두 DW 스타일 데이터베이스에 대한 페이지 압축 권장 (읽기 / 독점, 빅 데이터 작업)을 권장하는 편향되어 있습니다.

1-2 년 된 하드웨어에 대한 내 자신의 실험에서 나온 2 센트 :

페이지 압축 테이블 (~ 80 행 / 페이지)에 대한 읽기 전용 작업 (DW 스타일 스캔, 정렬 등) ~ 3 배의 압축 크기 감소에서조차조차없는 것으로 나타났습니다.

즉, 테이블이 메모리에 맞으면 페이지 크기가 데이터 크기가 3 배 이상 줄어든 경우에만 페이지 압축으로 성능이 향상됩니다. 메모리에서 더 적은 페이지를 스캔하지만 각 페이지를 스캔하는 데 시간이 더 걸립니다.

나는 생각 계획이 중첩 된 루프를하고 추구-무거운 경우 마일리지는 다를 수 있습니다. 그 중에서도 하드웨어에 따라 다릅니다 (외국 NUMA 노드 액세스 페널티, 메모리 속도 등).

위의 내용은 자체 하드웨어 (Dell Poweredge 910 이하)에서 자체 쿼리를 사용하여 자체 테스트를 수행 한 결과를 따르는 대략적인 규칙입니다. 복음이 아닙니다!

편집 : 어제 Thomas Kejser의 우수한 SQLBits XI 프레젠테이션이 비디오로 제공되었습니다. 이 논의와 관련하여 페이지 압축에 대한 CPU 비용의 '못생긴'얼굴을 보여줍니다.

그러나 Thomas는 FusionIO 스토리지를 사용하고 있으며 페이지 압축에 적합한 '테이블'만 선택했습니다. 스토리지가 일반적인 SAN에 있고 데이터에 압축 된 3x-4x가 사용 된 경우 그림의 성능이 떨어질 수 있습니다.

내 Data Warehouse 환경에서 몇 마디 만 추가 할 수 있습니다.

30 밀리언 행 (18GB)의 테스트 테이블에서 압축 (내 경우에는 PAGE)을 구현하면 테이블 크기가 18GB에서 3GB로 줄어 듭니다! (스토리지 효율성)로드 시간 (쓰기)을 22 분에서 36 분으로 늘립니다.

따라서 데이터를 읽거나 읽고 메모리에 저장하면 좋은 솔루션이 될 수 있지만 매일 데이터를로드하면 성능이 저하 될 수 있습니다.