-
Tuple Mover 모범 사례VERTICA/99.Best Practices 2017. 4. 4. 19:08
Vertica 분석 플랫폼은 WOS라고 하는 메모리에 작은 용량의 데이터 파일을 소량 로드하거나, ROS라고 하는 파일 시스템에 큰 용량의 데이터 파일을 대량 로드할 수 있는 스토리지 옵션을 지원합니다. WOS에 로드되는 데이터는 정렬되지 않은 상태로 저장되는 반면 ROS에 로드되는 데이터는 프로젝션 설계에 따라 정렬되거나, 인코딩되거나, 압축된 상태로 저장됩니다.
Tuple Mover는 백그라운드에서 실행되는 Vertica 서비스로서 두 가지 작업을 수행합니다.
- 무브아웃(Moveout): Tuple Mover 무브아웃 작업은 데이터를 WOS 컨테이너에서 새로운 ROS 컨테이너로 주기적으로 이동시켜 WOS가 가득 차서 ROS로 넘치는 것(스필오버)을 방지합니다. 이 작업은 특정 WOS 컨테이너 세트에서 한 번에 프로젝션 하나씩 실행됩니다. 프로젝션을 선택하여 ROS로 이동시킬 때는 이전에 커밋된 모든 트랜잭션에서 로드된 프로젝션 데이터를 병합하여 단일 ROS 컨테이너에 작성합니다.
- 머지아웃(Mergeout): Tuple Mover 머지아웃 작업은 ROS 컨테이너를 병합한 후 삭제된 레코드를 제거합니다.
대부분 실제 사용 사례에서 Tuple Mover는 기본 매개 변수를 벗어난 구성은 거의 또는 전혀 필요하지 않습니다. 단, 일부 워크로드는 구성 매개 변수를 약간 튜닝해야 하는 경우도 있습니다. 본 문서에서는 다음과 같은 내용을 포함하고 있습니다.
- 자주 묻는 질문에 대한 답변
- 문제 해결 팁 제공
- WOS, 데이터 로딩 및 스키마 설계에 대한 모범 사례(Best Practice) 설명
본 문서에서 제공하는 정보는 Tuple Mover 작업 및 시스템 효율을 높이는 데 도움이 될 것입니다.
WOS 메모리는 WOSDATA라는 이름으로 기본 제공되는 리소스 풀을 통해 제어되며, 최대 메모리 크기의 기본값은 노드당 2GB입니다. Tuple Mover의 데이터 이동 속도보다 WOS의 데이터 로드 속도가 더 빠르면 WOS 공간에 여유가 생길 때까지 데이터가 ROS로 넘쳐 이동합니다. 이러한 스필오버로 인한 데이터 손실은 없지만 느린 무브아웃 작업 때문에 ROS 컨테이너를 생성하는 속도가 예상보다 빨라질 수 있습니다.
다음 쿼리를 실행하여 데이터베이스의 WOS 스필오버 여부를 감지할 수 있습니다.
=>SELECT node_name, count(*) from dc_execution_engine_events
WHERE event_type = ‘WOS_SPILL’
group by node_name;다음 모범 사례(Best Practice)에 따라 Tuple Mover 무브아웃 작업의 원활하고 올바른 실행 여부를 확인할 수 있습니다.
대용량 데이터 파일 로드를 위한 COPY DIRECT 사용
대용량 데이터 파일(노드당 100MB 이상)을 로드하는 경우에는 COPY 문을 COPY DIRECT 문으로 전환합니다. 그러면 파일을 WOS로 로드하지 않고 직접 ROS로 로드할 수 있습니다.
WOS의 50%를 채우는 시간보다 작은 값으로 이 매개 변수를 설정합니다. 이 매개 변수는 WOS에서 이동시킬 데이터가 없는 상황에서 Tuple Mover 무브아웃 작업의 대기 시간(초)을 결정합니다. 이 매개 변수의 기본값은 30초이며, 값을 줄이면 WOS에서 ROS로 이동하는 데이터의 주기가 더욱 짧아집니다.
커밋되지 않은 데이터를 필요 이상으로 WOS에 남겨두지 마십시오. Tuple Mover는 커밋된 데이터만 이동시키기 때문입니다. WOS가 커밋되지 않은 트랜잭션 데이터로 가득 차면 무브아웃 작업으로 데이터를 이동시킬 수 없습니다. 그에 따라 ROS에 대한 WOS 스필오버가 발생할 수 있습니다.
WOS를 사용하여 대용량 데이터 세트(노드당 50MB 이상)가 저장된 임시 테이블을 로드하지 마십시오. 무브아웃 작업은 임시 테이블 데이터를 이동시키지 않기 때문에 트랜잭션이나 세션이 종료되면 데이터가 삭제됩니다.
데이터를 10개 이상의 테이블에 동시에 소량 로드하면서 WOS 스필오버가 발생할 경우에는 앞에서 얘기한 모범 사례(Best Practice) 중 한 가지 이상이 문제를 해결하는 데 도움이 될 것입니다. WOS 리소스 풀의 maxMemorySize를 높게 설정하여 WOS 메모리 크기를 늘릴 수 있습니다. 데이터를 다수의 테이블에 공격적으로 로드하는 경우가 아니라면, 그리고 프로젝션 1개당 WOS의 데이터가 수백 메가바이트를 넘지 않는다면 WOS 메모리 크기를 늘리지 마십시오. 프로젝션 1개당 WOS의 데이터 크기가 수백 메가바이트를 넘는 경우에는 쿼리 성능이 불안정할 수 있습니다.
공간 활용도를 기반으로 무브아웃 작업을 실행할 수 있는 적합성 기준을 설정할 때 이 매개 변수를 사용합니다. 이 매개 변수는 데이터를 소수의 테이블에 소량 로드할 때 유용합니다. 이 경우에는 무브아웃 작업이 데이터를 WOS에서 적극적으로 이동시켜 작은 크기의 ROS 컨테이너를 짧은 주기로 생성할 수 있습니다. 예를 들어 이 값을 40으로 설정하면 WOS가 40% 찰 때까지 프로젝션을 이동시키지 않기 때문에 무브아웃 작업 전에 데이터를 배치 처리하는 데 효과적입니다.
Tuple Mover가 시간(초)을 기준으로 무브아웃 작업을 시작하기 전에 WOS에 저장되는 데이터의 크기를 설정할 때 이 매개 변수를 사용합니다. 이 매개 변수의 기본값은 1800입니다. MoveOutSizePct 매개 변수의 값을 변경하면 이 매개 변수의 값을 600으로 바꿀 수 있습니다.
안 됩니다. 무브아웃 스레드의 기본값은 1이며, 이 값을 변경할 수는 없습니다.
MoveOutInterval 매개 변수를 변경하려면 어떻게 해야 하며, 변경 사항은 언제 적용됩니까?
이 구성 매개 변수는 vsql에서 set_config_parameter 명령을 실행하여 변경할 수 있습니다. 매개 변수 변경은 향후 무브아웃 작업 대기 상태에 영향을 줍니다. 다음은 이 매개 변수 값을 120초로 변경하는 예제입니다.
=>SELECT set_config_parameter(‘MoveOutInterval’,120);
노드에서 무브아웃 작업이 실행 중인지 확인하려면 어떻게 해야 합니까?
다음 SQL 문을 실행하면 Tuple Mover의 작업 진행 상황을 확인할 수 있습니다.
=>SELECT * from tuple_mover_operations where is_executing;
프로젝션에 대한 데이터의 무브아웃 작업을 수행할 경우 테이블에 대해 U 잠금(lock)을 사용합니다. 마크 삭제(delete marks) 또는 삭제 재생(replay deletes)을 관리할 때는 테이블에 대해 T 잠금(lock)을 사용합니다.
- T 잠금(lock)을 얻지 못할 경우 무브아웃 작업이 중단 또는 차단됩니다. 장시간 실행 중인 트랜잭션이 동일한 테이블에서 X 잠금(lock)을 사용하고 있을 경우 이러한 일이 발생할 수 있습니다.
- 장시간 동안 머지아웃 작업을 실행 중인 ROS 컨테이너를 참조하고 있는 deleted vector를 이동시키려고 하면 무브아웃 작업이 중단 또는 차단됩니다.
- 또한 테이블에서 1,024개가 넘는 파티션을 WOS로 로드하려고 해도 무브아웃 작업이 중단됩니다.
Tuple Mover 머지아웃 작업은 백그라운드에서 실행되는 Vertica 서비스로서 ROS 컨테이너를 병합합니다. 노드마다 프로젝션 1개당 최대 ROS 컨테이너 수는 1,024개입니다. 데이터 로드 중 "TOO MANY ROS CONTAINERS"라는 오류 메시지가 표시되면 노드마다 프로젝션 1개당 최대 ROS 컨테이너 수에 도달한 것을 의미합니다. 머지아웃 작업은 정상적인 사용 환경에서 데이터베이스가 최대 수에 도달하지 않았는지 확인하고 ROS 컨테이너를 병합하여 그 수를 줄입니다.
다음 모범 사례(Best Practice)에 따라 Tuple Mover 머지아웃 작업의 원활한 실행 여부를 확인하고 ROS 컨테이너 수를 줄일 수 있습니다.
WOS를 사용한 소량 로드(Trickle Load) 또는 DIRECT HINT를 사용한 배치 로드
WOS에 소량 로드할 경우 데이터를 디스크로 이동하기 전에 배치 처리할 수 있어서 생성되는 ROS 컨테이너의 수를 줄이는 데 효과적입니다. 대용량 파일의 경우에는 DIRECT HINT를 사용하여 데이터를 ROS에 직접 배치 로드합니다.
데이터베이스에 컬럼의 수가 100개 이상인 와이드 테이블이 있을 경우 TM 리소스 풀의 MemorySize를 기본값 200MB에서 6GB로 높이고 PLANNEDCONCURRENCY 매개 변수를 3으로 변경합니다. 와이드 테이블에서 작업 속도를 높이려면 Tuple Mover 머지아웃 스레드 1개당 2GB 이상을 예약하십시오.
Vertica는 파티션끼리는 ROS 컨테이너를 병합하지 않으므로 테이블 1개당 생성되는 파티션 수는 50개 미만으로 유지하는 것이 좋습니다. 따라서 파티션 수가 수백 개인 테이블은 ROS 푸시백(pushback)이 빠르게 발생할 수 있습니다. 테이블의 파티션 스킴은 ALTER TABLE ALTER PARTITION 명령을 사용하여 변경 가능합니다.
중요: 오래 되어 더 이상 액세스하지 않는 파티션이 있는 경우에는 MOVE_PARTITION_TO_TABLE 함수를 사용하여 아카이브 테이블로 이동시킬 수 있습니다.
구성 매개 변수: ActivePartitionCount
현재 사용하는, 또는 가장 최근의 비활성 파티션에 데이터가 저장되는 횟수가 잦은 경우에는 ActivePartitionCount 매개 변수를 기본값인 1에서 2로 변경합니다. Vertica는 시간 기반 파티션으로 인식하여 하나는 데이터를 저장하는 활성 파티션으로, 나머지는 데이터를 거의 또는 전혀 저장하지 않는 비활성 파티션으로 사용합니다. Tuple Mover는 비활성 파티션의 ROS 컨테이너를 단일 ROS 컨테이너로 병합합니다.
프로젝션 세트가 2개 이상 동일한 테이블에 속해서는 안 됩니다. 테이블 1개당 프로젝션 세트가 2개 이상이면 시스템 리소스를 낭비할 수 있습니다.
정렬 순서에 포함되는 컬럼의 수는 10개 미만으로 유지하고, 와이드 VARCHAR 컬럼이 정렬 순서에 포함되지 않도록 하십시오. 정렬 순서에 포함되는 컬럼의 수를 제어하려면 먼저 정렬 순서에 컬럼의 수가 적게 테이블 프로젝션을 새롭게 변경하고, 와이드 VARCHAR 컬럼이 정렬 순서에 포함되지 않도록 해야 합니다. 이렇게 하면 머지아웃 작업의 실행 시간을 줄이는 데 효과적입니다. 장시간 실행 중인 작업은 머지아웃 스레드를 차단하여 ROS 컨테이너의 수가 늘어나는 원인이 될 수 있습니다.
삭제 및 삭제 재생(replay deletes)을 위한 프로젝션의 최적화
높은 cardinality 컬럼을 정렬 순서의 마지막 컬럼으로 사용하여 프로젝션을 삭제에 최적화합니다. 이렇게 하면 삭제 재생(replay deletes)으로 인해 머지아웃 작업의 장시간 실행을 방지할 수 있습니다. 머지아웃 작업이 삭제 재생(replay deletes)으로 인해 장시간 실행될 때는 close_session(<session_id>) 함수를 사용해 작업을 취소합니다. 그런 다음 make_ahm_now 함수를 실행하여 AHM(Advanced History Mark) 에포크(epoch)를 앞당겨 시작합니다. AHM이 끝난 후에는 삭제가 재생되지 않아 머지아웃 작업의 실행 속도가 더욱 빨라집니다. 삭제 재생(replay deletes)으로 인해 머지아웃 작업이 장시간 실행될 때는 시간이 지나면서 ROS 컨테이너가 누적될 수 있습니다.
재구성(Reorganize) 작업의 상태는 PARTITION_STATUS 시스템 테이블에서 확인할 수 있습니다. 파티션 표현식은 변경되지만 재구성(Reorganize) 표현식이 시작되지 않거나 중단된 경우 변경 이전 테이블에 속한 프로젝션의 ROS 컨테이너는 테이블을 재구성(Reorganize) 할 때까지 머지아웃 작업이 불가능합니다. 이 문제는 다음과 같은 방법으로 해결할 수 있습니다.
=>ALTER TABLE <TABLE_NAME> REORGANIZE;
가능한 경우 삭제와 업데이트를 배치 처리합니다. 삭제 또는 업데이트를 자주 실행해야 한다면 WOS를 사용하여 삭제를 더욱 적은 수의 삭제 벡터(delete vector)로 병합하는 것이 좋습니다. 이렇게 하면 프로젝션 1개당 삭제 벡터(delete vector)의 수가 지나치게 많아져 ROS 컨테이너 수가 늘어나는 것을 방지할 수 있습니다.
주기적으로 프로젝션마다 생성되는 ROS 컨테이너의 수가 ROS 푸시백(pushback) 제한을 초과하지 않도록 이 매개 변수를 기본값 600에서 조정합니다.
TM 리소스 풀의 MaxConcurrency 및 PlannedConcurrency
앞에서 언급한 모범 사례(Best Practice)들을 고려하고 있지만 워크로드에 머지아웃 스레드가 추가로 필요한 경우에는 TM 리소스 풀의 MaxConcurrency 및 PlannedConcurrency 매개 변수를 3에서 4로 변경합니다. 기본값은 무브아웃 스레드 1개와 머지아웃 스레드 2개, 총 3개입니다. 이 값을 6보다 크게 높이지 마십시오.
MergeOutCache를 사용한 머지아웃 개선
Vertica 7.1.2-6에서는 MergeOutCache라는 작업 분석 도구가 추가되면서 Tuple Mover 알고리즘의 효율성이 향상되었습니다. MergeOutCache의 추가로 Tuple Mover는 실행해야 하는 머지아웃 작업을 더욱 빠르게 식별할 수 있습니다. 테이블이 수백 개인 대용량 카탈로그가 있는 경우에는 Vertica 7.1.2-6 또는 최신 Vertica 패치로 업그레이드하는 것이 좋습니다.
Tuple Mover의 머지아웃 계층(스트라타) 알고리즘은 어떻게 구현됩니까?
Tuple Mover 머지아웃 작업은 계층 기반 알고리즘을 사용합니다. 이 알고리즘은 데이터 로드 프로세스가 동작하는 중에도 각 튜플이 적은 횟수지만 지속적으로 머지아웃 작업 대상인지 확인할 수 있도록 개발되었습니다. 머지아웃 작업은 이 알고리즘을 사용하여 파티션이 없는 테이블과 파티셔닝된 테이블의 활성 파티션에 어떤 ROS 컨테이너를 병합할지 선택합니다.
Vertica는 각 활성 파티션과 파티셔닝되지 않은 테이블에 속한 프로젝션에 계층을 형성합니다. 계층의 수와 각 계층의 크기, 그리고 계층의 최대 ROS 컨테이너 수는 디스크 크기와 메모리, 그리고 프로젝션의 컬럼 수를 기준으로 계산됩니다.
다음은 알고리즘이 ROS 컨테이너를 크기에 따라 각 계층으로 분류하는 방식을 나타낸 그래프입니다. 계층 0의 ROS 컨테이너는 모두 ROS 크기(컬럼 1개당 1MB 이하)를 무시해도 좋습니다. 보라색 점이 ROS 컨테이너를 나타냅니다.대용량의 ROS 컨테이너 병합에 앞서 작은 크기의 ROS 컨테이너를 먼저 병합하여 머지아웃 알고리즘의 장점을 극대화합니다. 알고리즘은 1바이트부터 무시해도 좋은 ROS 청크 크기까지 속한 계층 0에서 시작하여 상향 이동합니다. 상향 이동하면서 각 계층의 ROS 컨테이너 수가 한 계층에 허용된 최대 ROS 컨테이너 수 이상의 값에 도달했는지 확인합니다. 기본값은 32입니다. 이때 알고리즘이 가득 찬 계층을 발견하면 프로젝션과 계층을 머지아웃에 적합한 것으로 마크합니다.
머지아웃 작업은 전체 계층의 ROS 컨테이너를 병합하여 새로운 ROS 컨테이너를 생성하며, 이렇게 생성된 컨테이너는 대부분 다음 계층으로 할당됩니다. 또한 계층 0을 제외하고 ROSPerStratum 값과 동일한 수의 ROS 컨테이너만 병합합니다. 계층 0에서는 적합한 ROS 컨테이너를 모두 단일 ROS 컨테이너로 병합합니다.
기본적으로 머지아웃 작업은 스레드가 2개입니다. 일반적으로 높은 계층의 대용량 ROS 컨테이너 머지아웃이 낮은 계층의 ROS 컨테이너 머지아웃보다 시간이 오래 걸립니다. 머지아웃 스레드 0은 비교적 높은 계층과 비활성 파티션에서만 작업합니다. 이러한 제한으로 인해 비교적 낮은 계층에서는 ROS 컨테이너의 누적이 어렵습니다. 그 이유는 머지아웃 스레드 0은 비교적 높은 계층에서 머지아웃을 실행하는 데 시간이 더 많이 걸리기 때문입니다. 머지아웃 스레드 1은 비교적 낮은 계층에서만 동작합니다.
참고: 머지아웃 스레드를 추가하더라도 추가된 스레드는 비교적 낮은 계층에서만 동작합니다.
비활성 파티션에서 유효한 머지아웃 스레드는 몇 개입니까?
머지아웃 스레드 0은 비활성 파티션에서만 동작하여 비활성 파티션의 ROS 컨테이너를 단일 ROS 컨테이너로 병합합니다. 단, 스레드 0은 계층 알고리즘에 따라 머지아웃에 적합한 프로젝션이 더 이상 존재하지 않는 경우에 한해서 비활성 파티션에서 동작합니다.
Tuple Mover는 계층 알고리즘에 따라 머지아웃에 적합한 ROS 컨테이너에서 AHM 이전에 삭제된 데이터만 제거합니다. 비활성 파티션에서 삭제된 데이터 역시 제거할 수 있습니다. 하지만 제거를 위해서는 비활성 파티션을 포함하여 ROS 컨테이너에서 삭제된 데이터 비율이 PurgeMergeoutPercent 매개 변수의 값보다 커야 합니다. 이 매개 변수의 기본값은 20입니다.
다음 구성 매개 변수는 언제, 어떻게 사용할 수 있습니까?
매개 변수
기능
ROSPerStratum
한 계층의 ROS 컨테이너 수입니다. 계층이 기본값 32에 도달하면 프로젝션의 머지아웃이 가능합니다. 이 값을 줄이면 더 많은 머지아웃 작업에 레코드가 사용되어 I/O가 증가하지만 ROS 컨테이너의 수는 감소합니다.
MaxDVROSPerContainer
단일 ROS 컨테이너에 연결된 삭제 벡터(delete vector)의 수가 기본값 10에 도달하면 Tuple Mover 머지아웃 작업이 삭제 벡터(delete vector)를 병합합니다.
임의의 프로젝션에 대한 활성 파티션을 찾으려면 어떻게 해야 합니까?
다음 명령을 사용하여 임의의 프로젝션에 대한 활성 파티션을 찾을 수 있습니다.
=>SELECT DISTINCT partition_key FROM strata;
WHERE projection_name <projection_name>
AND schema_name <schema>각 노드의 프로젝션당 컨테이너 수를 찾으려면 어떻게 해야 합니까?
다음 명령을 사용하여 각 노드의 프로젝션당 컨테이너 수를 찾을 수 있습니다.
=>SELECT node_name, schema_name, projection_name,
sum(delete_vector_count) delete_vector_count, count(*) ROS_container_count, sum(delete_vector_count) + count(*) total_container_count
FROM storage_containers
GROUP BY 1,2,3 ORDER BY 6 DESC;'VERTICA > 99.Best Practices' 카테고리의 다른 글
Vertica 임포트 및 익스포트의 이해 (0) 2017.11.28 Spread 디버깅 (0) 2017.05.10 댓글
