Amazon Redshift는 패치 198부터 새 Python UDF 생성을 더 이상 지원하지 않습니다. 기존 Python UDF는 2026년 6월 30일까지 계속 작동합니다. 자세한 내용은 [블로그 게시물](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)을 참조하세요. # 테이블 Vacuum Amazon Redshift는 백그라운드의 테이블에서 VACUUM DELETE 작업을 자동으로 정렬하고 수행할 수 있습니다. 로드 또는 일련의 증분적 업데이트 후 테이블을 정리하기 위해 전체 데이터베이스나 개별 테이블에 대해 [VACUUM](r_VACUUM_command.md) 명령을 실행할 수도 있습니다. **참고** 필요한 테이블 권한이 있는 사용자만 테이블을 유효하게 정리(vacuum)할 수 있습니다. 필요한 테이블 권한 없이 VACUUM을 실행할 경우 작업은 성공적으로 완료되지만 아무런 효과도 없습니다. VACUUM을 유요하게 실행하기 위한 유효한 테이블 권한 목록은 [VACUUM](r_VACUUM_command.md) 섹션을 참조하세요. 이러한 이유로 필요에 따라 개별 테이블에 대해 VACUUM을 실행하는 것이 좋습니다. 또한 전체 데이터베이스에 대해 vacuum을 실행하면 비용이 많이 필요하므로 이 방법을 권장합니다. ## 자동 테이블 정렬 Amazon Redshift는 백그라운드에서 데이터를 자동으로 정렬하여 정렬 키 순서대로 테이블 데이터를 유지합니다. Amazon Redshift는 스캔 쿼리를 추적하여 정렬이 유용한 테이블 섹션을 결정합니다. 또한 Amazon Redshift는 동시성 조정 클러스터에서 스캔 쿼리를 추적합니다. Amazon Redshift 데이터 공유를 사용하는 다중 클러스터 아키텍처의 경우 Amazon Redshift는 여러 리전의 클러스터/작업 그룹을 포함하여 데이터 메시의 소비자 클러스터/작업 그룹에서 시작된 스캔 쿼리도 추적합니다. 기본 클러스터, 동시성 조정 클러스터 및 소비자 클러스터의 스캔 통계가 집계되어 정렬의 이점을 누릴 테이블 섹션을 결정합니다. 시스템의 로드에 따라 Amazon Redshift가 자동으로 정렬을 시작합니다. 이 자동 정렬은 데이터를 정렬 키 순서로 유지하기 위해 VACUUM 명령을 실행할 필요성을 줄입니다. 예를 들어 대량의 데이터 로드 후 정렬 키 순서로 전체 정렬된 데이터가 필요한 경우에도 VACUUM 명령을 수동으로 실행할 수 있습니다. 테이블이 VACUUM SORT 실행을 통해 이익을 얻을 수 있는지 확인하려면 [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md)의 `vacuum_sort_benefit` 열을 모니터링하세요. Amazon Redshift는 각 테이블에서 정렬 키를 사용하는 스캔 쿼리를 추적합니다. Amazon Redshift는 각 테이블에 대한 데이터 스캔 및 필터링 개선의 최대 비율을 추정합니다(테이블이 전체 정렬된 경우). 이 추정값은 `vacuum_sort_benefit`의 [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md) 열에서 볼 수 있습니다. 이 열을 `unsorted` 열과 함께 사용하면 테이블에서 VACUUM SORT를 수동으로 실행하여 쿼리가 이익을 얻을 수 있는 시기를 결정할 수 있습니다. 이 `unsorted` 열은 테이블의 물리적 정렬 순서를 반영합니다. `vacuum_sort_benefit` 열은 VACUUM SORT를 수동으로 실행하여 테이블 정렬의 영향을 지정합니다. 예를 들어 다음 쿼리를 고려해 보세요. ``` select "table", unsorted,vacuum_sort_benefit from svv_table_info order by 1; ``` ``` table | unsorted | vacuum_sort_benefit -------+----------+--------------------- sales | 85.71 | 5.00 event | 45.24 | 67.00 ``` 테이블 "sales"의 경우 테이블의 \$186%가 물리적으로 정렬되지 않은 경우에도 86%의 정렬되지 않은 테이블로부터 얻는 쿼리 성능 영향은 5%에 불과합니다. 이는 쿼리에서 테이블의 일부에만 액세스하거나 테이블에 액세스하는 쿼리가 거의 없기 때문일 수 있습니다. “event” 테이블의 경우, 테이블은 \$145%가 물리적으로 정렬되지 않았습니다. 그러나 쿼리 성능 영향이 67%라는 의미는 쿼리에서 테이블의 많은 부분에 액세스하거나 테이블에 액세스하는 쿼리 수가 많음을 나타냅니다. "event" 테이블은 VACUUM SORT를 실행할 때 이익을 얻을 가능성이 있습니다. ## 자동 vacuum 삭제 삭제를 수행하면 행이 삭제 표시되지만 제거되지는 않습니다. Amazon Redshift는 데이터베이스 테이블에서 삭제된 행 수를 기준으로 백그라운드에서 VACUUM DELETE 작업을 자동으로 실행합니다. Amazon Redshift는 로드가 감소한 기간 동안 VACUUM DELETE가 실행되도록 예약하고 부하가 많은 기간 동안 작업을 일시 중지합니다. **Topics** + [자동 테이블 정렬](#automatic-table-sort) + [자동 vacuum 삭제](#automatic-table-delete) + [VACUUM 빈도](#vacuum-frequency) + [정렬 단계 및 병합 단계](#vacuum-stages) + [vacuum 임계값](#vacuum-sort-threshold) + [vacuum 유형](#vacuum-types) + [Vacuum 시간 최소화](vacuum-managing-vacuum-times.md) ## VACUUM 빈도 일관된 쿼리 성능을 유지하기 위해서는 필요할 때마다 자주 vacuum을 수행해야 합니다. VACUUM 명령을 얼마나 자주 실행할지 결정할 때는 다음 요인을 고려하세요. + 저녁이나 지정된 데이터베이스 관리 기간 같이 클러스터에서의 활동이 최소일 것으로 예상되는 기간에 VACUUM을 실행합니다. + 유지 관리 기간 외 시간에 VACUUM 명령을 실행합니다. 자세한 내용은 [유지 관리 기간 관련 일정](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html)을 참조하세요. + 정렬되지 않은 리전이 많으면 vacuum 시간이 길어집니다. vacuum을 연기하면 다시 정리해야 하는 데이터가 많아지기 때문에 vacuum에 더 많은 시간이 소요됩니다. + VACUUM은 I/O를 많이 사용하는 작업이므로 vacuum 완료까지 걸리는 시간이 길어질수록 클러스터에서 실행되는 동시 쿼리와 그 밖의 데이터베이스 작업에 미치는 영향이 커집니다. + 인터리브 정렬을 사용하는 테이블의 경우, VACUUM 시간이 길어집니다. 인터리브 테이블을 다시 정렬해야 하는지 평가하려면 [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) 보기를 쿼리합니다. ## 정렬 단계 및 병합 단계 Amazon Redshift는 2단계로 vacuum 작업을 수행합니다. 먼저 정렬되지 않은 리전의 행을 정렬한 다음 필요할 경우 테이블 끝에 있는 새로 정렬된 행을 기존의 행과 병합합니다. 큰 테이블을 vacuum하는 경우, vacuum 작업은 증분적 정렬 후 병합으로 구성되는 일련의 단계로 진행됩니다. 작업이 실패하거나 vacuum 도중 Amazon Redshift가 오프라인 상태가 되는 경우 부분적으로 vacuum된 테이블이나 데이터베이스는 일관된 상태가 되지만 vacuum 작업을 수동으로 다시 시작해야 합니다. 증분적 정렬은 손실되지만 실패 전에 커밋된 병합된 행들은 다시 vacuum할 필요가 없습니다. 정렬되지 않은 리전이 클 경우, 상당한 시간을 손해 볼 수 있습니다. 정렬 및 병합 단계에 대한 자세한 내용은 [병합된 행의 볼륨 줄이기](vacuum-managing-vacuum-times.md#vacuum-managing-volume-of-unmerged-rows) 섹션을 참조하세요. 테이블이 vacuum되는 동안 사용자는 테이블에 액세스할 수 있습니다. 테이블이 vacuum되는 중에도 쿼리 및 쓰기 작업을 수행할 수 있지만 DML과 vacuum이 동시에 실행되고 있을 때는 두 작업 모두 시간이 더 소요될 수 있습니다. vacuum 도중에 UPDATE 및 DELETE 문을 실행하는 경우 시스템 성능이 저하될 수 있습니다. 증분적 병합은 동시적인 UPDATE 작업과 DELETE 작업을 일시적으로 차단하며 UPDATE 작업과 DELETE 작업은 해당 테이블에서 증분적 병합 단계를 차단합니다. ALTER TABLE 같은 DDL 작업은 테이블의 vacuum 작업이 끝날 때까지 차단됩니다. **참고** VACUUM에 대한 다양한 수정자가 작동 방식을 제어합니다. 이를 사용하여 현재 요구 사항에 맞게 vacuum 작업을 조정할 수 있습니다. 예를 들어 VACUUM RECLUSTER를 사용하면 전체 병합 작업을 수행하지 않아 vacuum 작업이 단축됩니다. 자세한 내용은 [VACUUM](r_VACUUM_command.md) 섹션을 참조하세요. ## vacuum 임계값 기본적으로 VACUUM은 테이블 행의 95% 이상이 이미 정렬된 테이블에 대해서는 정렬 단계를 건너뜁니다. 정렬 단계를 건너뛰면 VACUUM 성능을 상당히 개선할 수 있습니다. 단일 테이블의 기본 정렬 임계값을 변경하려면 VACUUM 명령을 실행할 때 테이블 이름과 TO *threshold* PERCENT 파라미터를 포함시킵니다. ## vacuum 유형 다양한 vacuum 유형에 대한 자세한 내용은 [VACUUM](r_VACUUM_command.md) 섹션을 참조하세요. # Vacuum 시간 최소화 Amazon Redshift는 백그라운드에서 자동으로 데이터를 정렬하고 VACUUM DELETE를 실행합니다. 이렇게 하면 VACUUM 명령을 실행할 필요성이 줄어듭니다. Vacuum은 시간이 많이 걸릴 수 있는 프로세스입니다. 데이터의 성격에 따라 다르지만, Vacuum 시간을 최소화하려면 다음과 같은 방식을 따르는 것이 좋습니다. **Topics** + [reindex 실행 여부 결정](#r_vacuum-decide-whether-to-reindex) + [정렬되지 않은 리전 크기 줄이기](#r_vacuum_diskspacereqs) + [병합된 행의 볼륨 줄이기](#vacuum-managing-volume-of-unmerged-rows) + [정렬 키 순서로 데이터 로드](#vacuum-load-in-sort-key-order) + [시계열 테이블을 사용하여 저장된 데이터 줄이기](#vacuum-time-series-tables) ## reindex 실행 여부 결정 인터리브 정렬 스타일을 사용하면 종종 쿼리 성능을 크게 높일 수 있지만 정렬 키 열의 값 분산이 변경되면 시간이 지남에 따라 성능이 저하될 수 있습니다. COPY 또는 CREATE TABLE AS를 사용하여 비어 있는 인터리브 테이블에 처음 로드할 때는 Amazon Redshift가 인터리브 인덱스를 자동으로 구축합니다. INSERT를 사용하여 인터리브 테이블에 처음 로드하는 경우에는 이후 VACUUM REINDEX를 실행하여 인터리브 인덱스를 초기화해야 합니다. 시간이 지나면서 새로운 정렬 키 값이 포함된 행을 추가하여 정렬 키 열의 값 분산이 바뀌면 성능이 떨어질 수 있습니다. 하지만 새로운 행이 기존 정렬 키 값의 범위만 벗어나지 않는다면 인덱스를 다시 빌드할 필요가 없습니다. VACUUM SORT ONLY 또는 VACUUM FULL을 실행하여 정렬 순서를 복원하세요. 쿼리 엔진은 정렬 순서를 사용하여 쿼리 처리를 위해 스캔해야 하는 데이터 블록을 효율적으로 선택할 수 있습니다. 인터리브 정렬의 경우 Amazon Redshift는 정렬 키 열 값을 분석하여 최적의 정렬 순서를 결정합니다. 행이 추가되어 키 값의 분산이 변경되거나 스큐되면 정렬 전략이 더 이상 최적이 아니게 되며, 정렬의 성능상 이득이 저하됩니다. 정렬 키 분산을 다시 분석하기 위해 VACUUM REINDEX를 실행할 수 있습니다. reindex 작업은 시간이 많이 걸리므로 reindex가 테이블에 이득이 될지 결정하려면 [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) 뷰를 쿼리하세요. 예를 들어 다음 쿼리는 인터리브 정렬 키를 사용하는 테이블의 세부 정보를 보여 줍니다. ``` select tbl as tbl_id, stv_tbl_perm.name as table_name, col, interleaved_skew, last_reindex from svv_interleaved_columns, stv_tbl_perm where svv_interleaved_columns.tbl = stv_tbl_perm.id and interleaved_skew is not null; tbl_id | table_name | col | interleaved_skew | last_reindex --------+------------+-----+------------------+-------------------- 100048 | customer | 0 | 3.65 | 2015-04-22 22:05:45 100068 | lineorder | 1 | 2.65 | 2015-04-22 22:05:45 100072 | part | 0 | 1.65 | 2015-04-22 22:05:45 100077 | supplier | 1 | 1.00 | 2015-04-22 22:05:45 (4 rows) ``` `interleaved_skew`의 값은 스큐의 양을 나타내는 비율입니다. 값이 1이면 적용된 제한이 없는 것입니다. 스큐가 1.4보다 크면 일반적으로 스큐가 기본 집합에 내재하지 않는 한 VACUUM REINDEX로 성능이 개선됩니다. `last_reindex`의 날짜 값을 사용하면 마지막 reindex 후 얼마나 지났는지 확인할 수 있습니다. ## 정렬되지 않은 리전 크기 줄이기 이미 데이터가 포함되어 있는 테이블에 대량의 새 데이터를 로드하거나 일상적 유지 관리 작업의 일환으로 테이블을 vacuum하지 않으면 정렬되지 않은 리전이 늘어납니다. vacuum 작업이 오래 실행되는 것을 방지하려면 다음과 같은 습관을 들이세요. + 정기적인 일정에 따라 vacuum 작업을 실행합니다. 테이블을 조금씩 증분하여 로드하는 경우(테이블의 전체 행 수의 작은 비율에 해당하는 일일 업데이트 등), 정기적으로 VACUUM을 실행하면 개별 vacuum 작업이 빠르게 진행되는 데 도움이 됩니다. + 가장 큰 로드를 먼저 실행합니다. COPY 작업을 여러 번 사용하여 새 테이블을 로드해야 하는 경우, 가장 큰 로드를 먼저 실행합니다. 새 테이블이나 잘린 테이블에 첫 로드를 실행할 때는 정렬된 리전으로 모든 데이터가 직접 로드되므로 vacuum이 필요하지 않습니다. + 모든 행을 삭제하는 대신 테이블을 자릅니다. 테이블에 행을 삭제해도 vacuum 작업을 수행할 때까지는 행이 차지하던 공간이 회수되지 않습니다. 그러나 테이블을 자르면 테이블이 비워 지고 디스크 공간이 회수되므로 vacuum이 필요하지 않습니다. 또는 테이블을 삭제하고 다시 만드세요. + 테스트 테이블을 자르거나 삭제합니다. 테스트 목적으로 소수의 행을 테이블에 로드하는 경우, 로드가 끝난 후 행을 삭제하지 마세요. 그 대신 테이블을 자르고 후속 프로덕션 로드 작업의 일환으로 이 행들을 다시 로드합니다. + 전체 복사를 수행합니다. 복합 정렬 키를 사용하는 테이블에 정렬되지 않은 큰 리전이 있는 경우, 전체 복사가 vacuum보다 훨씬 빠릅니다. 전체 복사는 대량 삽입을 사용하여 테이블을 다시 생성하고 다시 채움으로써 테이블을 자동으로 다시 정렬합니다. 테이블에 정렬되지 않은 큰 리전이 있는 경우, 전체 복사가 vacuum보다 훨씬 빠릅니다. 반면 전체 복사 작업 중에는 vacuum 중에는 가능한 동시 업데이트를 할 수 없다는 단점이 있습니다. 자세한 내용은 [Amazon Redshift 쿼리 설계 모범 사례](c_designing-queries-best-practices.md) 섹션을 참조하세요. ## 병합된 행의 볼륨 줄이기 vacuum 작업이 새 행을 테이블의 정렬된 리전에 병합해야 하는 경우, 테이블이 커질수록 vacuum에 필요한 시간이 늘어납니다. 병합해야 하는 행의 수를 줄이면 vacuum 성능을 높일 수 있습니다. vacuum 전에 테이블은 테이블 헤드에 있는 정렬된 리전과 그 뒤에 오는, 행이 추가되거나 업데이트될 때마다 증가하는 정렬되지 않은 리전으로 구성됩니다. COPY 작업에 의해 행 세트가 추가되면 새로운 행 세트는 테이블 끝에 있는 정렬되지 않은 리전에 추가될 때 정렬 키에서 정렬됩니다. 새 행들은 자체 세트 안에서는 정렬되어 있지만 정렬되지 않은 리전 안에서는 그렇지 않습니다. 다음 다이어그램은 2회 연속 COPY 작업 후의 정렬되지 않은 리전을 보여 주며, 여기서 정렬 키는 CUSTID입니다. 이 예에는 간단히 하기 위해 복합 정렬 키가 나와 있지만 정렬되지 않은 리전의 효과가 더 크다는 점만 제외하면 인터리브 정렬 키에도 동일한 원리가 적용됩니다. ![\[두 COPY 작업의 레코드를 보관하는 정렬되지 않은 테이블입니다.\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/images/vacuum-unsorted-region.png) vacuum은 2단계로 테이블의 정렬 순서를 복원합니다. 1. 정렬되지 않은 리전을 새로 정렬된 리전으로 정렬합니다. 첫 번째 단계는 비교적 리소스를 적게 사용하는데 정렬되지 않은 리전만 다시 작성되기 때문입니다. 새로 정렬된 리전의 정렬 키 값의 범위가 기존 범위보다 높다면 새 행들만 다시 작성하면 되며, vacuum이 완료됩니다. 예를 들어 정렬된 리전에 ID 값 1\$1500이 포함되어 있고 후속 복사 작업이 500보다 큰 키 값을 추가하는 경우, 정렬되지 않은 리전을 재작성하면 됩니다. 1. 새로 정렬된 리전과 이전에 정렬된 리전을 병합합니다. 새로 정렬된 리전의 키가 정렬된 리전의 키와 중첩되는 경우, VACUUM은 행을 병합해야 합니다. vacuum은 새로 정렬된 리전의 시작 부분(가장 낮은 정렬 키)에서 시작해 이전에 정렬된 리전과 새로 정렬된 리전의 병합된 행들을 새 블록 세트에 작성합니다. 새 정렬 키 범위와 기존 정렬 키의 중첩 정도는 이전에 정렬된 리전을 어느 정도까지 다시 작성해야 하는지 결정합니다. 정렬되지 않은 키가 기존 정렬 범위 전체에 흩어져 있는 경우, vacuum은 테이블의 기존 부분을 다시 작성해야 할 수 있습니다. 다음 다이어그램은 CUSTID가 정렬 키인 테이블에 추가되는 행들을 vacuum이 어떻게 정렬하고 병합하는지 보여 줍니다. 각각의 복사 작업이 기존 키와 중첩되는 키 값을 가진 새로운 행 세트를 추가하기 때문에 거의 테이블 전체를 다시 작성해야 합니다. 이 다이어그램에는 단일 정렬 및 병합이 나와 있지만 실제로 큰 vacuum은 일련의 증분적 정렬 및 병합 단계로 구성됩니다. ![\[2단계로 구성된 예제 테이블의 VACUUM 작업입니다. 먼저 새 행이 정렬된 다음 기존 행과 병합됩니다.\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/images/vacuum-unsorted-region-sort-merge.png) 새로운 행 세트의 정렬 키 범위가 기존 키의 범위와 중첩되는 경우, 병합 단계 비용은 테이블이 커지는 데 따라 테이블 크기에 비례하여 계속 증가하는 반면 정렬 단계의 비용은 정렬되지 않은 리전의 크기에 여전히 비례합니다. 이런 경우, 다음 다이어그램에서 보듯 병합 단계의 비용은 정렬 단계의 비용과의 비교가 무색합니다. ![\[새 행에 정렬 키가 기존 행과 중복되면 병합 단계가 어떻게 더 많은 비용이 드는지 보여 주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/images/vacuum-example-merge-region-grows.png) 테이블 중에서 다시 병합된 비율을 확인하려면 vacuum 작업이 완료된 후 SVV\$1VACUUM\$1SUMMARY를 쿼리합니다. 다음 쿼리는 시간이 흐르면서 CUSTSALES가 계속 커짐에 따른 6회 연속 vacuum의 효과를 보여 줍니다. ``` select * from svv_vacuum_summary where table_name = 'custsales'; table_name | xid | sort_ | merge_ | elapsed_ | row_ | sortedrow_ | block_ | max_merge_ | | partitions | increments | time | delta | delta | delta | partitions -----------+------+------------+------------+------------+-------+------------+---------+--------------- custsales | 7072 | 3 | 2 | 143918314 | 0 | 88297472 | 1524 | 47 custsales | 7122 | 3 | 3 | 164157882 | 0 | 88297472 | 772 | 47 custsales | 7212 | 3 | 4 | 187433171 | 0 | 88297472 | 767 | 47 custsales | 7289 | 3 | 4 | 255482945 | 0 | 88297472 | 770 | 47 custsales | 7420 | 3 | 5 | 316583833 | 0 | 88297472 | 769 | 47 custsales | 9007 | 3 | 6 | 306685472 | 0 | 88297472 | 772 | 47 (6 rows) ``` merge\$1increments 열은 각각의 vacuum 작업을 위해 병합된 데이터 양을 표시합니다. 연속적 vacuum 동안 병합 증분의 수가 테이블 크기 증가에 비례하여 증가하는 경우, 이는 기존의 정렬된 리전과 새로 정렬된 리전이 중첩되기 때문에 각각의 vacuum 작업이 다시 병합하는 이 테이블의 행이 증가하고 있다는 뜻입니다. ## 정렬 키 순서로 데이터 로드 COPY 명령을 사용하여 데이터를 정렬 키 순서로 로드하면 vacuum 필요성을 줄이거나 심지어 없앨 수도 있습니다. 다음이 모두 참인 경우, COPY는 새 행을 테이블의 정렬된 리전에 자동으로 추가합니다. + 테이블이 하나의 정렬 열에만 복합 정렬 키를 사용합니다. + 정렬 열은 NOT NULL입니다. + 테이블이 100% 정렬되어 있거나 비어 있습니다. + 모든 새 행은 삭제 대기 상태인 행을 포함하여 기존 행보다 정렬 순서가 더 높습니다. 이 인스턴스에서 Amazon Redshift는 정렬 키의 첫 8바이트를 사용하여 정렬 순서를 결정합니다. + COPY 명령은 특정 로드 최적화를 트리거하지 않습니다. 대용량 데이터를 로드할 때 Amazon Redshift는 테이블의 정렬된 리전에 행을 추가하는 대신 정렬된 파티션을 새로 생성하여 성능을 최적화할 수 있습니다. 예를 들어 고객 ID와 시간을 사용하여 고객 이벤트를 기록하는 테이블이 있다고 가정해 보세요. 고객 ID에서 정렬하는 경우, 앞의 예에서 보듯 증분적 로드에 의해 추가된 새 행의 정렬 키 범위가 기존 범위와 중첩되어 vacuum 작업이 리소스를 많이 사용하게 됩니다. 정렬 키를 타임스탬프 열로 설정하면 다음 다이어그램에 나온 것처럼 새 행들이 테이블 끝에서 정렬 순서로 추가되어 vacuum 필요성이 줄어들거나 심지어 없어집니다. ![\[타임스탬프 열을 정렬 키로 사용하여 정렬할 필요가 없는 새 레코드를 가져오는 테이블입니다.\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/images/vacuum-unsorted-region-date-sort.png) ## 시계열 테이블을 사용하여 저장된 데이터 줄이기 롤링 기간 동안 데이터를 유지하는 경우, 다음 다이어그램에 나온 것처럼 시계열 테이블을 사용하세요. ![\[5분기의 데이터가 포함된 테이블 5개입니다. 가장 오래된 테이블이 삭제되어 1년의 롤링 시간을 유지합니다.\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/images/vacuum-example-unsorted-region-copy-time-series.png) 데이터 세트를 추가할 때마다 새 테이블을 만든 다음 시계열에서 가장 오래된 테이블을 삭제합니다. 두 가지 장점이 있습니다. + DROP TABLE 작업이 대량 DELETE보다 훨씬 효율적이기 때문에 행 삭제에 따른 비용 추가를 피할 수 있습니다. + 테이블이 타임스탬프를 기준으로 정렬되면 vacuum이 필요 없습니다. 각 테이블에 한 달 동안의 데이터가 포함된 경우, 테이블이 타임스탬프를 기준으로 정렬되어 있지 않더라도 vacuum이 다시 써야 하는 데이터 양은 한 달치에 불과합니다. 데이터가 여러 테이블에 저장되어 있다는 사실을 감추는, 보고 쿼리가 사용할 UNION ALL 뷰를 생성할 수 있습니다. 쿼리가 정렬 키에서 필터를 적용하는 경우, 쿼리 플래너는 사용되지 않는 모든 테이블을 효율적으로 건너뜁니다. 다른 유형의 쿼리에는 UNION ALL이 비효율적일 수 있으므로 테이블을 사용하는 모든 쿼리의 컨텍스트에서 쿼리 성능을 평가해야 합니다.