Vertica 파티션: 자주 묻는 질문

원문은 여기 : https://my.vertica.com/kb/HPE-Vertica-Partitions-The-FAQs/Content/FAQs/HPE-Vertica-Partitions-The-FAQs.htm

Vertica 파티션: 자주 묻는 질문(FAQ)

목차

 

Hewlett Packard Enterprise Vertica 파티셔닝 기능은 대용량 테이블 1개를 하나 이상의 컬럼 값에 따라 더욱 작은 파티션으로 분할합니다. 

이번 문서에서 살펴보겠지만 파티셔닝은 데이터 수명 주기를 더욱 쉽게 관리할 뿐만 아니라 파티션 표현식에 조건절의 조건이 포함되는
쿼리의 성능을 개선할 수 있는 기능입니다.

 

본 문서에서는 Vertica 데이터베이스의 파티션과 관련하여 발생할 수 있는 가장 중요한 질문에 대한 해답을 살펴보겠습니다. 

각 질문에 해당하는 카테고리는 다음과 같습니다.

• 파티션 기본 정보
• 파티션 및 스토리지 프루닝(pruning)
• 파티션, ROS 파일 및 ROS 컨테이너
• 재파티셔닝과 재구성
• 파티션 제한 사항

 

파티션 기본 정보

파티션은 어떻게 실행됩니까?

데이터 보존 정책을 만들어야 한다면 어떨까요? 예를 들어 5년까지만 데이터를 보존해야 한다고 가정하겠습니다. 

그렇다면 5년이 지난 데이터는 모두 삭제해야 합니다.

Vertica 파티셔닝 기능은 이러한 데이터를 효율적으로 관리할 수 있도록 지원합니다. 이러한 원리에 대해 살펴보겠습니다.

 

다음과 같은 데이터가 저장된, trade라는 이름의 테이블이 있다고 가정하겠습니다.

• 트레이드 날짜(tdate)
• 티커 기호(tsymbol)
• 트레이드 시간(ttime)

다음과 같이 CREATE TABLE 문을 사용하여 Vertica가 트레이드 발생 연도를 기준으로 데이터를 파티셔닝하도록 지정합니다.

=> CREATE TABLE trade (    tdate DATE NOT NULL,    tsymbol VARCHAR(8) NOT NULL,    ttime TIME)    PARTITION BY EXTRACT(year FROM tdate);

데이터를 trade 테이블에 로드하면 Vertica가 파티션 표현식(이번 예제에서는 연도)을 기준으로 데이터를 구분합니다

PARTITION BY EXTRACT(year FROM tdate)

이러한 파티셔닝에서는 파티션 관리 함수를 사용해 데이터 서브세트를 이동시키거나 삭제하는 등 쉽게 관리할 수 있습니다.

 

먼저 trade 테이블 예제에서 2008년 데이터를 로드한다고 가정하겠습니다. 

Vertica는 데이터를 ROS(Read Optimized Store) 컨테이너에 저장합니다

 

Vertica가 2008년 데이터에 대한 모든 ROS 컨테이너를 저장할 파티션을 생성합니다. 

가장 최근에 생성한 파티션을 활성 파티션(Active Partition)이라고 합니다. 

다음은 파티션에 로드된 2008년 데이터 2개 행을 나타낸 이미지입니다.

그런 다음 2009년 데이터를 처음 로드할 때 Vertica가 활성 파티션으로서 새로운 파티션을 생성합니다. 

다음은 Vertica가 2009년 데이터 2개 행을 새로운 파티션에 로드한 이미지입니다. 

비활성 파티션(inactive partition)에는 자주 액세스할 필요가 없는 데이터가 저장됩니다.

비활성 파티션(inactive partition)에 대해 머지아웃(mergeout) 작업을 실행할 경우에는 Tuple Mover가 모든 ROS 컨테이너를 
단일 ROS 컨테이너로 병합합니다. 

활성 파티션(active partition)에서는 Tuple Mover가 계층(스트라타) 기반 알고리즘을 사용하여 ROS 컨테이너를 병합합니다.

 

다음은 2008년과 2009년 파티션에 대한 전체 ROS 컨테이너와 활성 파티션(active partition)에 새롭게 로드된 데이터를 나타낸 이미지입니다.

 

참고: 활성 파티션(active partition)과 ROS 컨테이너에 대한 자세한 내용은
이 설명서의 파티션, ROS 파일 및 ROS 컨테이너 섹션을 참조하십시오.

 

파티셔닝과 세그먼트화(Segmentation)의 차이는 무엇입니까?

세그먼트화(segmentation)는 데이터를 클러스터 노드로 균일하게 분산시켜서 MPP(대용량 병렬 처리) 아키텍처를 이용하는 데 효과적입니다.

 

파티셔닝은 각 노드에서 데이터를 여러 다른 스토리지 컨테이너로 구성하는 데 효과적입니다. 

또한 I/O를 줄여서 쿼리 성능을 높일 수도 있습니다.

 

팩트 테이블에 적어도 다음과 같은 2개의 컬럼이 있다고 가정하겠습니다.

• 트랜잭션 ID(trans_id)
• 트랜잭션 날짜(trans_date)

다음은 팩트 테이블을 생성할 때 반드시 필요한 작업입니다.

• HASH 컬럼(trans_id)을 기준으로 테이블 프로젝션을 세그먼트화(segmentation)하여 데이터를 모든 노드에 균일하게 분산시킵니다.
• 일 기준으로 테이블을 파티셔닝합니다.

이러한 테이블 정의에 따라 각 파티션의 데이터는 모든 클러스터 노드로 균일하게 분산됩니다. 특정 파티션을 대상으로
쿼리를 병렬 실행할 수 있는 것도 이러한 세그먼트화(segmentation) 덕분입니다. 

다음은 데이터 분산 방법을 나타낸 간단한 예제입니다.

활성 파티션(Active Partition)이란 무엇입니까?

앞서 얘기했지만 테이블의 활성 파티션(active partition)이란 마지막에 업데이트한 파티션이 아닌 마지막에 생성한 파티션을 말합니다. 

활성 파티션(active partition)에는 자주 로드하는 데이터가 저장됩니다.

테이블 1개당 활성 파티션(active partition)의 수는 ActivePartitionCount 구성 매개 변수를 변경하여 바꿀 수 있습니다. 기본값은 1입니다.

 

Tuple Mover는 비활성 파티션(inactive partition)의 스토리지 컨테이너를 단일 ROS 컨테이너로 병합하여
파티션 1개당 ROS 컨테이너 1개를 만듭니다. 

그리고 데이터 병합 방법을 결정하는 계층(strata) 알고리즘을 사용하여 활성 파티션(active partition)의 스토리지 컨테이너를 병합합니다.

 

데이터를 마지막 파티션 2개에 자주 로드하는 경우에는 ActivePartitionCount를 2로 변경합니다. 

이것은 전역 구성 매개 변수이기 때문에 모든 테이블에 적용됩니다. 

2로 설정하면 Tuple Mover가 마지막으로 생성한 2개 파티션에 계층(strata) 알고리즘을 적용합니다.

 

ActivePartitionCount 설정을 높이면 Tuple Mover 작업 수가 줄어듭니다. 하지만 프로젝션의 ROS 컨테이너 수가 너무 많아질 수도 있습니다.

 

프로젝션의 활성 파티션(active partition)은 다음 쿼리를 사용하여 찾을 수 있습니다.

=> SELECT DISTINCT partition_key FROM strata    WHERE projection_name ILIKE '%sktest%'    AND schema_name ILIKEe '%public%';  partition_key ---------------              5              8              9 (3 rows)

어떤 테이블을 파티셔닝해야 합니까?

Vertica는 대용량 팩트 테이블만 파티셔닝할 것을 권장합니다. 

용량이 작은 테이블이나 차원(dimension) 테이블은 파티셔닝하지 마십시오. 

그러지 않으면 ROS 컨테이너가 다수 생성되어 카탈로그 크기가 빠르게 증가하고 쿼리 성능에 영향이 미칠 수 있습니다.

 

사용량이 비교적 적은 데이터를 보관하려면 어떻게 해야 합니까?

데이터를 삭제할 필요 없이 보관 목적으로 장기간 데이터를 유지할 수 있습니다.

데이터를 보관할 생각이라면 이전 또는 오래된 파티션에 대한 스토리지 정책을 만드는 것이 좋습니다. 

이전 파티션은 속도가 비교적 느리고 저렴한 스토리지에 저장할 수 있습니다. 

이 옵션은 더욱 빠른 고가의 스토리지에 여유 공간을 확보하여 자주 액세스하는 파티션을 빠르게 가져올 수 있습니다.

 

자세한 내용은 Vertica 설명서의 스토리지 정책 만들기 섹션을 참조하십시오.

 

테이블에 파티션을 정의할 때 무엇을 고려해야 합니까?

테이블에 파티션 표현식을 정의할 때 고려해야 할 사항은 다음과 같습니다.

• 데이터 보존 정책
• 자주 사용하는 쿼리 조건절
• 파티션 세분화가 각 노드 별 프로젝션 1개당 ROS 컨테이너 수와 각 노드 별 ROS 파일의 총 수에 미치는 영향

파티션 및 스토리지 프루닝(Pruning)

파티션은 데이터 수명 주기 관리에 어떤 영향을 줍니까?

Vertica 데이터베이스에서 대용량 팩트 테이블을 파티셔닝하면 데이터 수명 주기 관리가 더욱 쉬워질 뿐만 아니라
쿼리 성능까지 높일 수 있습니다.

 

Vertica 기능:

• 테이블에서 파티션을 삭제합니다.
• 거의 사용하지 않는 파티션을 아카이브 테이블로 이동시킵니다.
• 거의 사용하지 않는 파티션을 저가의 스토리지로 이동시킵니다.
• 아카이브에서 파티션을 복원합니다.

  파티션을 비롯한 연동 SQL 기능을 사용하여 데이터 보존 정책을 관리할 것을 적극 권장합니다.

 

스토리지 프루닝(Pruning)이란 무엇이며, 파티셔닝과 무슨 관련이 있습니까?

파티션 데이터는 개별 스토리지 컨테이너로 격리됩니다. 그 결과, 파티션 컬럼을 조건절에서 사용하는 쿼리는
Vertica 스토리지 프루닝(pruning) 기능을 통해 효과를 크게 높일 수 있습니다. 

스토리지 프루닝(pruning)의 작동 방식에 대해서 자세히 살펴보십시오.

 

쿼리 계획 단계에서 데이터베이스 옵티마이저는 쿼리에 필요한 데이터가 저장되지 않은 스토리지 컨테이너를 식별합니다. 

옵티마이저는 각 컨테이너의 파티셔닝 컬럼에서 최소값과 최대값을 근거로 이 정보를 구분합니다. 쿼리 처리 단계가 시작되면
Vertica 실행 엔진이 적용 값이 저장되지 않은 스토리지 컨테이너를 건너뛰어 I/O를 줄이고 쿼리 성능을 개선합니다.

 

3년간의 데이터가 월 기준으로 파티셔닝된 테이블이 있다고 가정하겠습니다. 

따라서 이 테이블의 데이터 파티션은 36개입니다. 다음은 네 가지 시나리오가 있습니다.

 

쿼리	스토리지 컨테이너 프루닝(pruning)
쿼리가 특정한 주 또는 월의 데이터를 분석합니다.	Vertica가 나머지 35개 파티션이 저장된 스토리지 컨테이너를 프루닝(pruning)합니다.
쿼리가 3개월 분기의 데이터를 분석합니다.	Vertica가 매월 1개씩 3개 파티션에 속한 스토리지 컨테이너를 사용하고 나머지를 프루닝(pruning)합니다.
쿼리에서 파티셔닝과 무관한 컬럼에 조건절이 있습니다.	이 쿼리는 조건절 컬럼의 데이터가 다수의 파티션에 존재할 가능성이 있기 때문에 스토리지 프루닝(pruning)을 효과적으로 사용하지 못합니다. 예: 테이블이 transaction_date를 기준으로 파티셔닝되어 있지만 쿼리의 zip_code 컬럼이 조건절이 있습니다.
쿼리가 파티셔닝 컬럼과 관련된 컬럼에 조건절이 있습니다.	이 쿼리는 가능하다면 스토리지 프루닝(pruning)을 이용합니다. 예: 쿼리의 ship_date 컬럼이 조건절이 있습니다. 일반적으로 ship_date는 transaction_date와 동일하거나 이후 월에 해당합니다. 이 경우 Vertica는 해당하는 2개 월의 파티션 2개를 제외하고 모두 프루닝(pruning)할 수 있습니다.

 

내 쿼리가 파티셔닝 및 스토리지 프루닝(pruning)을 이용하고 있는지 알고 싶다면 어떻게 해야 합니까?

쿼리에서 프루닝(pruning)된 스토리지 컨테이너의 수를 알아보려면 다음 단계를 수행하십시오.

1.다음과 같이 쿼리를 프로파일링하여 transaction_id와 statement_id를 확인합니다.

=> PROFILE SELECT * FROM <table_name> WHERE <column_name> BETWEEN 5 AND 7; NOTICE 4788:  Statement is being profiled HINT:  Select * from v_monitor.execution_engine_profiles where transaction_id=54043195528458555 and statement_id=1; NOTICE 3557:  Initiator memory for query: [on pool general: 19543 KB, minimum: 19543 KB] NOTICE 5077:  Total memory required by query: [19543 KB]  C1 ----  6  7  5 (3 rows)

2.QUERY_EVENTS 시스템 테이블에서 해당 트랜잭션이 있는지 보고 나서 쿼리 계획에서 해당 쿼리 실행 시
파티션의 처리 제거 여부를 확인합니다.

=> SELECT node_name , event_details FROM query_events WHERE       event_type = 'PARTITIONS_ELIMINATED' AND transaction_id = 54043195528458555    AND statement_id=1;     node_name     |                       event_details ------------------+----------------------------------------------------------- v_vmart_node0003  | Using only 1 stores out of 3 for projection public.tab_b0 v_vmart_node0002  | Using only 1 stores out of 5 for projection public.tab_b0 v_vmart_node0001  | Using only 1 stores out of 2 for projection public.tab_b0 (3 rows)

 

파티션, ROS 파일 및 ROS 컨테이너

 

ROS 파일과 ROS 컨테이너의 차이는 무엇입니까?

사용자가 DIRECT와 함께 COPY 문을 실행하면 Vertica는 컬럼 1개당 ROS 파일 1개를 생성합니다. 

ROS 컨테이너는 ROS 파일의 논리 그룹입니다. 

Vertica는 COPY DIRECT 또는 Tuple Mover의 작업 결과로 ROS 컨테이너를 생성합니다.

 

각 노드에서 프로젝션 1개당 ROS 컨테이너의 수를 고려해야 하는 이유는 무엇입니까?

Vertica는 파티션 데이터를 서로 다른 개별 스토리지 컨테이너로 격리합니다. Vertica는 여러 파티션의 데이터를 병합하지 않기 때문에
작은 파티션이 지나치게 많으면 스토리지 컨테이너의 수가 ROS 컨테이너의 최대 수(1024개)에 육박할 수 있습니다.  .

 

특정 프로젝션에서 이 최대 수에 도달했지만 새로운 데이터를 해당 프로젝션에 로드하려고 할 경우
"Too many ROS containers" 오류와 함께 로드가 중단됩니다. 

이러한 오류가 발생하면 다음 중 한 가지를 시도하십시오.

 

• ALTER_PARTITION을 사용하여 파티션 표현식을 세분화가 비교적 적은 파티션으로 변경합니다.
• MOVE_PARTITION을 사용하여 이전 파티션을 아카이브 테이블로 이동시킵니다.

노드 1개당 ROS 컨테이너의 총 수가 내 데이터베이스에 어떤 영향을 미칩니까?

노드 1개당 ROS 파일의 수는 다음과 같습니다.

(# storage containers) x (# columns per projection)

ROS 파일의 수는 카탈로그 크기가 커지는 가장 큰 요인입니다. 

카탈로그 크기가 크면 시스템 메모리를 소비하여 시스템 테이블 쿼리, 데이터베이스 시작, 데이터베이스 백업, 스크래치 복구 등
다른 데이터베이스 작업의 속도를 떨어뜨립니다.

 

노드당 ROS 파일의 수가 100만 개인 카탈로그는 크기가 약 3~4GB입니다. Vertica가 카타로그 메모리를 관리하기 전에
ROS 파일의 수가 증가하면 카탈로그 메모리가 해제되지 않을 수도 있습니다. 

이때는 Vertica가 카탈로그 메모리 해제를 다시 요구하면 이후부터 메모리를 사용할 수 있습니다. 

하지만 노드를 재부팅할 때까지는 메모리가 실제로 노드에서 해제되지 않습니다.

두 가지 유스 케이스를 살펴보겠습니다.

 

유스 케이스 1: 대용량 카탈로그

다음과 같은 데이터베이스가 있습니다.

• 테이블 1,000개
• 테이블당 프로젝션 2개
• 테이블당 컬럼 50개(평균)
• 노드당 ROS 컨테이너 50개
• 노드당 ROS 파일 약 500만 개

그렇다면 다음과 같이 프로젝션은 총 2,000개이고, ROS 파일은 총 500만 개입니다.

(1000 tables) x (2 projections per table) = 2000 projections (50 columns) x (2000 projections ) = 10,0000 x (50 ROS per projection) = 5,000,000 ROS files

테이블 300개를 일 기준으로 파티셔닝하여 데이터를 1년간 보존할 수 있습니다. 이 경우 Vertica 파티션 관리 함수를 사용하여 1일 단위로 데이터를 관리할 수 있습니다. 하지만 ROS 수가 최대 1,000만 개까지 추가되어 카탈로그의 크기가 2배에 이르게 됩니다.

(300 tables) x (2 projections) = 600 projections (365 days) x 600 = 219,000 x (50 columns) = 10,900,000 ROS files

이러한 상황에서는 두 가지 옵션이 있습니다.

• 일 기준으로 파티셔닝하면 노드마다 프로젝션 1개당 추가되는 ROS 컨테이너가 365개 이상입니다.
  따라서 소수의 테이블만 일 기준으로 파티셔닝하는 것이 좋습니다.
  용량이 작은 테이블은 파티셔닝을 피하고 가능하다면 대부분 테이블을 주 또는 월 기준으로 파티셔닝하는 것이 바람직합니다.
• 그래도 일 기준으로 파티셔닝해야 한다면 유사한 테이블을 단일 테이블로 병합하여 ROS 컨테이너의 수를 줄일 수 있습니다.
  스키마는 기존 OLTP 시스템에서 상속되어  테이블을 지리적 위치에 따라 다수의 테이블로 분할하여 쿼리 성능을 높이는 경우가 많습니다.
  이런 경우  다수의 테이블을 단일 테이블로 병합할 것을 권장합니다.
  
  

유스 케이스 2: 프로젝션 1개당 너무 많은 ROS 컨테이너

다음과 같은 데이터베이스가 있습니다.

 

• 테이블 100개
• 테이블당 프로젝션 2개
• 테이블당 열 50개
• 노드당 ROS 컨테이너 50개
• 노드당 ROS 파일 약 50만 개

그렇다면 다음과 같이 프로젝션은 총 200개이고, ROS 파일은 총 50만 개입니다.

 

(100 tables) x (2 projections per table)     = 200 projections (Average of 50 columns) x (200 projections)  =  10,000 x (50 ROS containers per projection) =  500,000 ROS files

테이블 10개를 일 기준으로 파티셔닝하여 데이터를 3년간 보존한다고 가정하겠습니다.
이 경우 파티션 관리 함수를 사용하여 1일 단위로 데이터를 관리할 수 있습니다.
이 시나리오에서는 다수의 ROS 파일이 누적되지 않습니다.
단, 3년이 지나기 전에 데이터를 로드하면 ROS 푸시백(pushback)이 발생합니다(ROS 컨테이너 1,024개).

1 table x (365 x 3) daily for 3 years = 1095  ROS containers for inactive partitions

결과적으로 활성 파티션(active partition)에서 데이터를 수신할 수 있는 공간은 남지 않습니다.

 

또한 주 기준으로 파티셔닝하는 경우는 다음과 같습니다.

1 table x (52 x 3) weekly for 3 years = 156 ROS containers for inactive partitions

이 대안에서는 생성되는 ROS 컨테이너가 매우 적습니다. 그렇다면 일 기준이 아닌 주 기준으로 데이터를 파티셔닝하는 것이 좋습니다.

향후 데이터 증가에 대비하여 파티션 계획 작성 시 이러한 문제를 고려하도록 권장합니다.  
다른 분석 애플리케이션 용도의 데이터를 Vertica로 마이그레이션하거나,
혹은 데이터베이스의 스토리지 최적화 및 성능을 경험한 후 더 많은 데이터를 보존할 수도 있기 때문입니다..

 

재파티셔닝(Repartitioning)과 재구성(Reorganizing)

 

파티셔닝되지 않은 테이블을 파티셔닝할 수 있습니까? 테이블의 파티션 표현식을 변경할 수 있습니까?

다음과 같이 기존 테이블을 파티셔닝하거나, 테이블의 파티션 표현식을 변경할 수 있습니다.

=> ALTER TABLE <table_name> PARTITION BY <partition_expression>

위 구문을 실행하면 스토리지 컨테이너의 기존 파티션 키 정보가 즉시 삭제됩니다.
그런 다음 REORGANIZE 키워드를 사용하여 새로운 파티션 표현식에 따라 이 정보를 재구성해야 합니다.

주의: 노드가 중단되었을 때는 테이블 파티셔닝을 변경하지 마십시오.

 

REORGANIZE 키워드를 사용하면 어떻게 됩니까?

PARTITION BY와 REORGANIZE 키워드를 따로 또는 함께 사용하면 테이블이 다음과 같이 파티셔닝 또는 재파티셔닝됩니다.

=> ALTER TABLE <table_name> PARTITION BY <partition_expression> REORGANIZE;

이 구문을 실행하면 Vertica가 기존 파티션 키를 삭제하고 테이블을 재파티셔닝 및 재구성합니다.

 

재구성 작업은 백그라운드에서 실행되는 Tuple Mover 작업이 변형된 형태입니다.
먼저 데이터베이스 성능에 영향을 미치지 않도록 데이터를 청크 단위로 읽습니다.
그런 다음 REORGANIZE가 새로운 파티셔닝 스킴에 따라 데이터를 ROS 컨테이너에 작성한 후
파티션 키를 ROS 컨테이너 오브젝트에 추가합니다.

 

REORGANIZE를 지연시킬 수 있습니까? 지연에 따른 영향은 무엇입니까?

재구성 작업은 실행 중인 데이터베이스의 성능을 최소화하기 위해 한 번에 ROS 컨테이너의 서브세트 하나에서만 실행됩니다.

재파티셔닝 이후 재구성 작업을 지연시키면 다음과 같은 제약이 따릅니다.

• 파티션 표현식이 변경 후 아직 재구성되지 않은 테이블에서는 파티션 함수를 실행할 수 없습니다.
• 파티셔닝된 테이블의 경우, 파티션 키가 없는 ROS 컨테이너는 Tuple Mover 머지아웃 작업에 참여하지 못합니다.
  이는 ROS 푸시백(pushback)의 원인이 될 수 있습니다.

  재파티셔닝 이후에는 최대한 빨리 재구성할 것을 권장합니다.
또한 변경된 테이블에 속한 프로젝션이 모두 완료될 때까지 재구성 작업의 진행 상황을 모니터링하십시오.

 

REORGANIZE 프로세스 상황을 모니터링하려면 어떻게 해야 합니까?

백그라운드에서 실행되는 재구성 작업은 다음 시스템 테이블을 사용하여 모니터링합니다.

 

• VS_TUPLE_MOVER_OPERATIONS
• PARTITION_STATUS
• PARTITION_REORGANIZE_ERRORS

임의 테이블의 파티션 이력을 보려면 시스템 테이블 CATALOG_EVENTS에 대한 쿼리를 실행합니다.

 

테이블 파티셔닝을 제거하려면 어떻게 해야 합니까?

더 이상 파티셔닝되지 않도록 테이블을 변경하려면 다음 문을 사용합니다. 

=> ALTER TABLE <table_name> REMOVE PARTITIONING;

테이블에서 파티셔닝을 제거하면 Vertica가 해당 파티션을 나머지 파티셔닝되지 않은 파티션과 동일하게 처리합니다.
Vertica가 계층(strata) 알고리즘을 사용하여 ROS 컨테이너를 병합합니다.

 

파티션 제한 사항

 

테이블 1개당 파티션 수에 제한이 있습니까?

테이블 1개당 파티션 수에는 제한이 없습니다. 하지만 파티션 데이터는 ROS 컨테이너로 격리됩니다.
Vertica는 노드마다 프로젝션 1개당 ROS 컨테이너의 수를 1,024개로 제한하고 있기 때문에
테이블 1개당 파티션의 수는 1,024개로 제한될 수 밖에 없습니다.

 

Vertica는 COPY DIRECT 문 하나로 파티션을 1,024개 이상 로드하지 못하도록 제한하고 있습니다.

따라서 파티션 수가 365개 이상(최대 수의 약 3분의 1)인 경우에는 프로젝션 1개당 ROS 컨테이너의 수를 지켜보면서
Tuple Mover 머지아웃 작업을 모니터링해야 합니다.
파티션 수가 365개 이상일 때는 해당 테이블의 파티셔닝 스킴을 재고하거나 쿼리를 실행하지 않는 파티션을
아카이브 테이블로 이동시키는 것이 좋습니다.

 

메모리에 상주하는 데이터베이스 카탈로그 크기를 측정하려면 어떻게 해야 합니까?

다음 쿼리는 데이터베이스 카탈로그의 크기를 출력합니다.

=> SELECT node_name, MAX (ts) AS ts, MAX(catalog_size_in_MB)    AS catlog_size_in_MB    FROM    (SELECT node_name,     TRUNC((dc_allocation_pool_statistics_by_second."time")::TIMESTAMP,     'SS'::VARCHAR(2)) AS ts,     SUM((dc_allocation_pool_statistics_by_second.total_memory_max_value     - dc_allocation_pool_statistics_by_second.free_memory_min_value))/(1024*1024)     AS catalog_size_in_MB from dc_allocation_pool_statistics_by_second GROUP BY 1,     TRUNC((dc_allocation_pool_statistics_by_second."time")::TIMESTAMP,     'SS'::VARCHAR(2))     )     subquery_1 GROUP BY 1 ORDER BY 1 LIMIT 50;

파티셔닝이 카탈로그 크기를 높이고 있는지 알고 싶다면 어떻게 확인할 수 있습니까?

대용량 데이터베이스 카탈로그의 원인이 되는 상황은 몇 가지 있습니다. 대용량 카탈로그란 10GB 이상인 카탈로그를 말합니다.

 

다음 쿼리는 ROS 컨테이너 수가 가장 많은 상위 50개의 프로젝션을 반환합니다. 이 결과에서 테이블이 파티셔닝되어 있고,
파티션 수가 높다면 HP Vertica가 파티션을 적게 생성할 수 있도록 파티셔닝 스킴을 수정하는 것이 좋습니다.

=> SELECT s.node_name, p.table_schema, s.projection_name,    COUNT(DISTINCT s.storage_oid) storage_container_count,    COUNT(DISTINCT partition_key) partition_count,    COUNT(r.rosid) ros_file_count    FROM storage_containers s LEFT OUTER JOIN PARTITIONS p    ON s.storage_oid = p.ros_id JOIN vs_ros r    ON r.delid = s.storage_oid    GROUP BY 1,2,3 ORDER BY 4 DESC LIMIT 50;

자세한 정보

파티셔닝에 대한 자세한 내용은 Vertica 설명서에서 다음 섹션을 참조하십시오.

• 테이블 파티션 사용
• 파티션 관리 함수