본문 바로가기
DBMS

MPP DBMS Greenplum Architecture (2) - opensource

by developer's warehouse 2023. 12. 1.

이 글에서는 그린플럼 아키텍처에 대해서 1편에 이어서 설명합니다.

MPP DBMS Greenplum Architecture

MPP DBMS Greenplum Architecture (2)


클라이언트가 마스터의 QD(Query Dispatcher: distributor) 프로세스에 쿼리 요청을 보내면, QD 프로세스는 원본 쿼리문을 구문 분석하고, 옵티마이저에 의해 분산 쿼리 계획을 생성한 후, libpq 프로토콜을 통해 각 세그먼트의 QE(Query Executor) 프로세스에 보내는 등 수신된 쿼리를 처리합니다.

각 세그먼트의 QD와 QE들은 상호 연결을 설정합니다. 여기서 주의해야 할 점은 Libpq는 주로 명령과 결과 반환을 제어하는 데 사용되며, 인터커넥트는 내부 데이터 통신으로 사용합니다.

각 QE 프로세스는 할당된 쿼리 하위 작업을 실행하고 결과를 QD로 반환합니다. QES는 또한 상호 연결을 통해 서로 상호 작용하며, libpq 링크는 없습니다. libpq 프로토콜은 오류 처리를 포함하여 QE와 QD 간의 상태를 업데이트하고 관리하는 데 사용됩니다. 최종 QD는 수집된 쿼리 결과를 요약하여 libpq를 통해 클라이언트에 반환합니다.

글로 보니 이해가 되지 않습니다. 어떤때 interconnect를 사용하는지 명확하지 않아서 그림으로 확인합니다.

일단,

클라이언트 쿼리 요청 to QD

 

QD는 QE에 task를 보냄

 

 

QD가 QE들과 통신하는것

위의 그림을 확인하면, QD가 연결등은 libpq를 이용하지만, 내부 플랜을 전달 받을 때 interconnect를 이용하고 있다고 보면 될 것 같습니다.

 

결과와 상태등은 다시 libpq 라이브러리를 통해 전달
 

요약하면, client가 libpq 라이브러리로 master의 QD에 접속하면 QD는 libpq라이브러리를 통해서 QE들의 컨트롤 정보를 생성 및 연결하고 실제 플랜은 interconnect를 통해 전달하여 실행합니다.

그 후, 실행 완료된 결과를 다시 libpq라이브러리의 통신 채널로 받아서 결과를 정리 후에 client에게 반환합니다.

QD는 쿼리 결과를 client에게 libqp를 이용해 반환

예를 들어 복잡한 쿼리를 수행할 때는 먼저 두 테이블을 선택한 다음 두 테이블을 조인합니다. 이때 전체 쿼리는 두 개의 계층으로 나뉩니다. 첫 번째 계층은 데이터를 읽은 다음 두 계층 간에 데이터를 교환합니다. 두 번째 계층은 동일한 링크 키의 값을 함께 조인하고 마지막으로 조인 결과를 클라이언트에 반환합니다. PostgreSQL은 처리할 각 쿼리에 대해 단일 프로세스를 생성하는 프로세스 모델입니다. CPU 사용률을 향상시키기 위해 Greenplum은 세그먼트에서 연산자 간 쿼리 병렬화를 구현합니다. 사용자 쿼리는 하나의 세그먼트에 여러 개의 QES를 가질 수 있으며, QES는 상호 연결을 통해 서로 상호 작용합니다.

오퍼레이터 병렬화
 

2 Phase Commit

앞서 언급했듯이 Greenplum에서는 데이터가 여러 세그먼트에 존재하므로 데이터를 쓸 때 세그먼트의 모든 데이터를 성공적으로 또는 실패하게 써야 합니다. 부분적으로 성공하고 부분적으로 실패하는 경우 데이터의 일관되지 않은 상태가 나타나는 것은 용납할 수 없는 일입니다.

여기서 고전적인 알고리즘인 2단계 제출 알고리즘(two-stage submission, 2 phase commit 이 더 적절해 보임)을 언급할 필요가 있습니다.
이름에서 알 수 있듯이 알고리즘은 두 단계로 구성됩니다. 첫 번째 단계에서는 모든 노드가 제출할 수 있는지 여부를 투표할 수 있도록 준비합니다. 모든 노드가 '예'라고 응답하면 두 번째 단계에서 제출됩니다. 그렇지 않으면 한 노드라도 예라고 응답하지 않으면 모든 노드가 롤백됩니다.

1. 1 단계 프리페어(Prepare)에서 실패시 abort

1 단계 프리페어에서 실패시 abort
 
2. 첫 번째 단계에서 모든 노드가 '예'라고 응답했지만 두 번째 단계에서 문제가 발생한 경우, DTM 관리자는 실패한 노드가 성공할 때까지 계속 제출합니다. 제출된 모든 정보는 DTM에 의해 로그에 저장되며, 이 정보를 통해 트랜잭션의 상태 정보를 복구하여 다음에 수행해야 할 작업을 파악할 수 있습니다.
 
2단계에서 커밋

 

원문 출처: https://greenplum.org/introduction-to-greenplum-architecture/

facebook twitter kakaoTalk kakaostory naver band shareLink