압축 인코딩 테스트 - Amazon Redshift

압축 인코딩 테스트

압축 인코딩을 수동으로 지정하는 경우 데이터를 이용해 여러 가지 인코딩을 테스트할 수 있습니다.

참고

가능하다면 항상 COPY 명령을 사용하여 데이터를 로드하고, COPY 명령에서 데이터에 따른 최적의 인코딩을 선택하도록 허용하는 것이 좋습니다. 또는 ANALYZE COMPRESSION 명령을 사용하여 기존 데이터에 적합한 인코딩을 확인하는 방법도 있습니다. 자동 압축 적용에 대한 자세한 내용은 자동 압축을 사용하여 테이블 로드 섹션을 참조하세요.

데이터 압축에 대한 유의적 테스트를 위해서는 다수의 행이 필요합니다. 이번 예에서는 임의의 테이블을 생성한 후 이 테이블이 VENUE 테이블과 LISTING 테이블에서 선택하는 문을 사용하여 행을 삽입합니다. 일반적으로 두 테이블을 조인하는 WHERE 절을 생략합니다. 결과적으로 VENUE 테이블의 각 행이 LISTING 테이블의 모든 행으로 조인되어 전체 행의 수는 3,200만 개가 됩니다. 이를 데카르트 조인이라고 하며 일반적으로 권장되지 않습니다. 그러나 이는 이러한 용도로 많은 행을 생성하는 편리한 방법입니다. 테스트할 데이터가 기존 테이블에 로드되어 있으면 이번 단계를 생략해도 좋습니다.

샘플 데이터가 있는 테이블을 생성한 후 7개의 열이 있는 테이블을 생성합니다. 각각 다른 압축 인코딩(raw, bytedict, lzo, run length, text255, text32k 및 zstd)이 있습니다. 첫 번째 테이블에서 데이터를 선택할 때 사용한 INSERT 명령을 실행하여 정확히 동일한 데이터로 각 열을 채웁니다.

압축 인코딩을 테스트하려면 다음을 수행합니다.

  1. (옵션) 먼저 데카르트 조인을 사용하여 다수의 행이 포함된 테이블을 하나 생성합니다. 기존 테이블을 테스트할 때는 이 단계를 생략해도 좋습니다.

    create table cartesian_venue(
venueid smallint not null distkey sortkey,
venuename varchar(100),
venuecity varchar(30),
venuestate char(2),
venueseats integer);

insert into cartesian_venue
select venueid, venuename, venuecity, venuestate, venueseats
from venue, listing;

  2. 비교할 인코딩을 적용하여 테이블을 생성합니다. 

    create table encodingvenue (
venueraw varchar(100) encode raw,
venuebytedict varchar(100) encode bytedict,
venuelzo varchar(100) encode lzo,
venuerunlength varchar(100) encode runlength,
venuetext255 varchar(100) encode text255,
venuetext32k varchar(100) encode text32k,
venuezstd varchar(100) encode zstd);

  3. SELECT 절에 INSERT 문을 사용하여 동일한 데이터를 모든 열에 삽입합니다. 

    insert into encodingvenue
select venuename as venueraw, venuename as venuebytedict, venuename as venuelzo, venuename as venuerunlength, venuename as  venuetext32k, venuename as  venuetext255, venuename as venuezstd
from cartesian_venue;

  4. 새로운 테이블에서 행의 수를 확인합니다.

    select count(*) from encodingvenue

  count
----------
 38884394
(1 row)

  5. STV_BLOCKLIST 시스템 테이블에 대해 쿼리를 실행하여 각 열에서 사용된 1MB 디스크 블록의 수를 비교합니다.

    MAX 집계 함수는 각 열마다 가장 높은 블록 수를 반환합니다. STV_BLOCKLIST 테이블에는 시스템에서 작성된 열 3개에 대한 세부 정보가 포함되어 있습니다. 다음 예는 WHERE 절에서 col < 6을 사용하여 시스템에서 작성된 열을 배제한 것입니다.

    select col, max(blocknum)
from stv_blocklist b, stv_tbl_perm p
where (b.tbl=p.id) and name ='encodingvenue'
and col < 7
group by name, col
order by col;

    위 쿼리는 다음과 같은 결과를 반환합니다. 열은 0부터 번호가 매겨집니다. 클러스터의 구성 방식에 따라 결과적으로 다른 번호가 될 수는 있지만 상대적 크기는 비슷해야 합니다. 이 데이터 집합에서는 두 번째 열에 있는 BYTEDICT 인코딩이 최상의 결과를 이끌어내는 것을 알 수 있습니다. 이 접근 방식의 압축 비율은 20:1보다 좋습니다. LZO 인코딩과 ZSTD 인코딩 역시 우수한 결과를 산출하였습니다. 물론 데이터 세트가 달라지면 결과도 바뀝니다. 열에 더욱 긴 텍스트 문자열이 포함되어 있으면 LZO 인코딩이 종종 최상의 압축 결과를 산출하기도 합니다.

     col | max
-----+-----
   0 | 203
   1 |  10
   2 |  22
   3 | 204
   4 |  56
   5 |  72
   6 |  20
(7 rows)

기존 테이블에 이미 데이터가 있다면 ANALYZE COMPRESSION 명령을 사용하여 테이블에 적합한 인코딩을 확인할 수도 있습니다. 예를 들어 다음 예는 행의 수가 3,800만 개인 VENUE 테이블(CARTESIAN_VENUE)을 복사하는 데 가장 적합한 인코딩을 나타내고 있습니다. 예를 보면, ANALYZE COMPRESSION을 실행한 결과 VENUENAME 열에는 LZO 인코딩을 적용하는 것이 바람직합니다. ANALYZE COMPRESSION은 감소율을 포함한 다수의 요인을 기준으로 최적의 압축 인코딩을 선택합니다. 이번 예와 같은 경우에는 BYTEDICT의 압축 성능이 우수하지만 LZO 역시 90%가 넘는 압축비를 보이고 있습니다.

analyze compression cartesian_venue;

Table          | Column     | Encoding | Est_reduction_pct
---------------+------------+----------+------------------
reallybigvenue | venueid    | lzo      | 97.54            
reallybigvenue | venuename  | lzo      | 91.71            
reallybigvenue | venuecity  | lzo      | 96.01            
reallybigvenue | venuestate | lzo      | 97.68            
reallybigvenue | venueseats | lzo      | 98.21