# Tibero Columnar Compression ## 개요 TCC는 압축률 향상과 디스크 I/O 감소에 도움을 주는 데이터 저장 방식입니다. TCC를 이용하면 기존의 방식(row의 column들을 연속으로 배치하는 것)을 대신하여 테이블의 각 컬럼들을 개별적으로 수집하여 연속으로 저장합니다. 아래와 같이 컬럼을 연속으로 배치할 경우, 동일한 데이터 패턴이 반복되어 RLE(Run-Length Encoding), LZ4(Lempel-Ziv 4), gzip(GNU zip), bzip2(block zip version 2)와 같은 압축 기법에 매우 효과적입니다.

그림 1. TCC 구성(Compression Unit)

### TCC 장점 * 압축률이 크게 향상됩니다. \ 데이터 패턴에 따라 차이가 나지만, 일반적인 OLAP 비즈니스 환경에서 4:1\~10:1의 압축률 향상을 기대할 수 있습니다. * 압축률이 향상되므로 전체 I/O가 줄어듭니다.\ I/O가 성능의 병목인 경우 성능향상을 도모할 수 있습니다. 또한 ZetaData는 SSVR 인스턴스에서 압축을 해제하기 때문에 DB 노드의 자원을 소모하지 않습니다. Storage 노드의 CPU 자원은 일반적으로 여유가 있는 경우가 많습니다. * 컬럼별로 배치되므로 불필요한 컬럼을 읽지 않습니다. \ 전체 컬럼수와 비교하여 필요한 컬럼이 적을 경우 I/O수행 횟수를 줄일 수 있습니다. 아래의 경우에 TCC를 사용하면 효과적입니다. #### **Update(**또는 **delete)**가 드물게 발생하는 테이블 위에서 설명한 바와 같이 TCC로 구성된 테이블에 대해 update가 일어나면 성능이 저하됩니다. 따라서 주로 DPL/DPI를 통해 대량으로 로딩하고, 데이터 라이프 사이클(Life Cycle)에 따라 테이블 전체를 따로 저장하거나 폐기하는 용도로 매우 적합합니다. #### **Full table scan**이 빈번하게 발생하는 테이블 주로 사용되는 쿼리가 Full table scan인 경우에 TCC를 추천합니다. Full table scan은 선택도(Selectivity) 에 따라 결정될 수도 있고, aggregation 사용 여부에 따라 결정될 수도 있습니다. #### 데이터 길이나 패턴이 일정하거나 비슷한 테이블 데이터 길이나 패턴이 일정하거나 비슷한 테이블의 경우 RLE, LZ4, gzip, bzip2와 같은 압축을 적용했을 때 좋은 압축률을 기대할 수 있습니다. 또한 로딩할 때 압축률이 거의 일정하면, 재압축 횟수가 줄어들어 로딩 속도도 향상됩니다. #### **Projectivity**가 큰 테이블 TCC 사용은 테이블의 일부 컬럼만 필요로 하는 경우에 특히 효과적입니다. 필요하지 않은 컬럼에 해당하는 CU(Compression Unit)는 읽지 않습니다. 만약, row-oriented로 저장되어 있다면 필요로 하는 컬럼 개수와 관계없이 row의 전체 컬럼을 읽어야 합니다. 따라서 상대적으로 읽어야하는 블록 숫자가 늘어납니다. *** ## 초기화 파라미터 아래는 TCC와 관련한 초기화 파라미터에 대한 설명입니다. CC\_CU\_BLKCNT는 시스템 파라미터이고 나머지 파라미터들은 세션 파라미터입니다.
파라미터설명
CC_CU_BLKCNT

CU(Compression Unit)가 가질 수 있는 최대 블록 개수입니다.

보통은 큰 CU가 압축에 유리하지만, 어느 정도 이상이 되면 많이 차이가 나지 않습니다. 불필요하게 CU가 크면 반복적인 압축 해제가 있는 경우 불리하게 작용할 수도 있습니다.

DB_FILE_MULTIBLOCK_READ_COUNT보다 작게 설정하는 것을 권장합니다. (기본값: 4, 범위: 1 - 32)

CC_CU_PCTUSECU에 들어갈 최소 용량 비율입니다.
CU를 구성할 때 최소 이 비율 이상을 채웁니다. 이 값이 크면 공간 낭비를 막을 수 있는 반면, 로딩할 때 재압축이 많아져서 성능이 저하될 수 있습니다. (기본값: 95, 범위: 0 - 99)
CC_TYPICAL_ROW_SIZE

압축될 데이터의 일반적인 row 크기입니다.

처음 압축을 시작할 때에 힌트로 사용됩니다. 이 값과 CC_EXPECTED_RATE를 이용해서 한 CU에 몇 개의 row가 들어갈지 예측해서 압축을 더 빠르게 진행시킬 수 있습니다. (기본값: 100, 범위: 3 - 1000)

CC_EXPECTED_RATE

압축될 데이터의 일반적인 압축 비율입니다(힌트).

CC_TYPICAL_ROW_SIZE와 함께 처음 CU를 구성할 때 쓰입니다. 이후 CU에 대한 예측은 직전 CU의 결과를 이용합니다.

(기본값: 25, 범위: 1 - 100)

CC_CU_WRITEOUT_THRESHOLD

CC_CU_WRITEOUT_THRESHOLD는 단일 블록이 쓰기 작업을 진행하기 위해 충족해야 하는 최소 채움 비율을 지정하는 설정입니다. 즉, 블록의 데이터가 설정된 비율 이상 채워졌을 때에만 해당 블록이 디스크에 기록됩니다.

(기본값: 85, 범위: 0 - 99)

*** ## **TCC** 테이블 생성 명령어 CREATE TABLE 명령을 수행할 때 아래의 옵션을 주어서 TCC 테이블을 만들 수 있습니다. ```sql CREATE TABLE {table-name} COMPRESS FOR QUERY LOW ``` 컬럼 압축 중에서는 OLTP성 업무로 인한 성능 손실을 최대한 막을 수 있는 레벨입니다. ```sql CREATE TABLE {table-name} COMPRESS FOR QUERY HIGH ``` 중간 정도의 압축 레벨입니다. 압축/해제의 성능도 중간 정도입니다. ```sql CREATE TABLE {table-name} COMPRESS FOR ARCHIVE LOW ``` 보다 높은 압축 레벨입니다. 압축/해제의 성능은 다소 떨어집니다. ```sql CREATE TABLE {table-name} COMPRESS FOR ARCHIVE HIGH ``` 최대 압축률입니다. 압축/해제의 성능도 제일 낮습니다. {% hint style="info" %} **참고** 컬럼 압축이 아닌 기존의 기본 압축 방식을 적용하기 위해서는 COMPRESS까지만 설정합니다. {% endhint %} 아래는 옵션을 사용한 예입니다. ```sql CREATE TABLE T(A NUMBER) COMPRESS FOR QUERY HIGH ``` *** ## **TCC** 사용 주의사항 TCC는 row-oriented 저장구조에 비해 장점만 있는 것은 아니기 때문에 잘못 사용하면 성능에 큰 손실을 입을 수 있습니다. 아래와 같은 경우는 주의해야 합니다. ### **Update(**또는 **Delete)**가 빈번하게 발생하는 테이블 TCC로 저장된 테이블에 update가 수행되면, 압축이 해제되고 해당 row는 row-oriented 로 변경됩니다. 또한 많은 경우에 row 단위로 읽는 방식보다 더 많은 블록을 읽어야 하는 특성이 있습니다. 예를 들어 UPDATE SET A=1, B=2 WHERE C=3을 처리할 때에 row-oriented로 저장되어 있으면 한 블록만 읽으면 되지만, TCC로 저장되어 있으면 세 개의CU를 읽어야 합니다. CC\_CU\_BLKCNT가 클 경우는 다음과 같은 상황에서 더욱 문제가 될 수 있습니다. 하나의 row를 처리하기 위해서 각 CU마다 CC\_CU\_BLKCNT만큼의 블록 I/O가 필요합니다. 따라서 압축효율의 큰 차이가 없다면, 적정 수준의 CC\_CU\_BLKCNT를 사용하는 것이 좋습니다. ### 인덱스를 통한 접근이 많은 테이블 인덱스를 통한 접근 시 항상 CU 단위로 압축을 해제합니다. (단, 연속된 rowid에 대해서는 압축 해제된 내용을 재사용합니다. 각각의 Row마다 항상 압축을 해제하는 것은 아닙니다.) 따라서 인덱스를 통한 접근 시 압축 해제가 빈번하게 발생할 수 있으므로, 성능 저하 가능성을 고려해야 합니다. 인덱스를 통한 접근과 같이, TCC 저장방식은 row 단위로 접근하는 모든 경우에 비효율적입니다. ### 제약조건 * TCC가 걸린 테이블에 drop column, set unused column, rowid를 사용하는 table redefinition이 불가능합니다. * TCC가 걸린 테이블에 bitmap index 생성이 불가능합니다. * LOB, LONG, XML, 사용자 정의형(nested table, varray, object 등) column type이 존재하는 테이블에 TCC 사용 불가능합니다. * 암호화된 테이블에 DPI 수행 시 압축이 되지 않습니다. * TCC가 걸린 테이블에 Merge, Split partition 수행 시 Update Global Indexes(UGI), Update Indexes(UI) 사용이 불가능합니다. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.tibero.com/zetadata/tibero-columnar-compression.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.