Expert Oracle Exadata 2-A. 오프로딩 / 스마트 스캔
- 소프트웨어 아키텍처:
1. 데이터베이스와 스토리지 계층 양쪽 모두에서 수행되는 구성 요소도 있다. 아래 그림에서 엑사데이터 플랫폼 전체 아키텍처가 묘사되어 있다.
위쪽 절반은 오라클 11g 아키텍처이다. 스토리지 서버의 아키텍처에는 데이터베이스 서버와 입출력하는 모든 통신을 처리하는 단 하나의 프로세스(cellsrv)만 있고 환경 관리 및 모니터링을 위한 몇몇 보조 프로세스가 있다. 스토리지 소프트웨어는 cellsrv가 init.ora 파일과 alert.log를 사용한다는 점이 많이 닮아있다. alert.log는 오라클 데이터베이스의 alert log처럼 주목할 만한 이벤트를 기록하기 위해 사용된다. 또한 ADR(Automatic Diagnostic Repository)가 진단 정보를 캡처하고 보고하기 위해 스토리지 소프트웨어의 일부분으로 포함된다.
1.1 DISKMON은 데이터베이스 인스턴스와 연결되어 있지 않고 엑사데이터 스토리지에 관련된 작업을 수행하는 프로세스이다. 셀이 살아있는지 확인하기위한 네트워크와 셀 모니터링 프로세스라고 볼 수 있다. 이것은 DBRM플랜을 스토리지 서버로 전달하고 인스턴스당 하나씩 슬레이브 프로세스를 가져 ASM과 데이터베이스 사이의 통신을 담당한다.
- 엑사데이터는 하드웨어와 소프트웨어의 매우 밀접하게 결합된 조합이다. 성능 향상의 대부분은 통합된 구성 요소와 스토리지 계층에 적용된 소프트웨어에서 온다.
- 오프로딩(Offloading):
1. 오프로딩은 데이터베이스 서버에서 하던 처리를 스토리지 계층으로 옮겨서 처리하는 개념을 일컫는다. 주요 이점으로 대형 데이터베이스의 주요 병목 중 하나인 데이터베이스 서버로 반환할 데이터의 양을 감소시킨다.
2. 스마트 스캔: 오프로딩과 다소 상호 교환되어 사용되는 용어이나 스마트 스캔은 단지 엑사데이터의 SQL 구문 최적화를 언급하는 데 더 중점을 둔다. 스마트 스캔이라는 용어가 포함된 wait 이벤트는 총 두 개로 cell smart table scan과 cell smart index scan이다.
3. 오프로딩의 중요성: 데이터베이스 서버로 대량의 데이터를 반환하여 처리해야 하기 때문에 디스크 액세스를 필요로 하는 쿼리는 모두 매우 비효율적이다. 제한된 용량의 버퍼 캐시에 모든 데이터를 올려놓을 수는 없다. 특히 대량의 데이터 액세스는 필히 대량의 물리적인 디스크 접근을 필요로 한다.
3.1. I/O를 개선하는 방법: 대용량의 버퍼 캐시를 구성하는 방법과 엑사데이터처럼 스토리지 레이어에서 오프로딩 처리를 하는 방법이 있다. 최신의 x64 서버 제품은 구조적으로 작은 메모리 구성에 더 이상 제약 받지 않으므로 대용량 메모리 지원을 받을 수 있다. 예를 들어 다량의 DIMM 슬록을 가진 다수의 메모리 채널을 지원하는 QPI(Quickpass Interconnector)를 가지는 프로세서에 기반한 서버가 있다. X2-8 엑사데이터 모델은 데이터베이스 그리드에서 2TB의 메인 메모리를 제공한다. 2023년 현재 최신 엑사데이터 모델인 X8M-2는 풀 랙 기준 11.1TB Total RAM 용량을 가진다. 엑사데이터는 In-memory parallel query기능과 높은 압축을 결합할 수 있다.
3.2. In-memory parallel query: 보통 병렬 쿼리가 direct path read를 하는 반면, 이는 SGA의 버퍼 캐시를 통해 병렬 쿼리 처리를 수행하여 디스크 I/O를 최소화한다. 큰 오브젝트를 버퍼 캐시에 캐시하기 위해 충분한 크기의 메모리가 필요하다.
3.3. Oracle Hybrid Columnar Compression: 압축을 하게 되면 블록이 압축된 채로 버퍼 캐시에 올라가므로 메모리를 더 적게 사용하는 장점이 있다.
4. 전통적인 오라클 데이터베이스에서는 한 개의 컬럼을 얻기 위해 적어도 데이터블록 하나(8K)를 메모리로 읽어 들여야 한다. 만약 테이블이 블록 하나당 평균 50개의 로우를 저장한다고 가정하면 하나의 로우와 하나의 컬럼에 해당하는 값 하나를 얻기위해 단지 오버헤드에 불과한 49개의 추가 로우를 데이터베이스 서버로 전송한다. 대형 데이터 웨어하우스에서는 여기에 수십억 배의 데이터 블록의 양을 전송하게 되므로 스토리지와 데이터베이스 계층 사이에 불필요한 데이터를 전송하는데 소요되는 시간을 제거하는 것이 바로 엑사데이터가 해결할 주요 문제이며 오프로딩이 그 해결책으로 제시되는 접근 방법이다.
5. 오프로딩 설계 목표:
5.1. 디스크 시스템에서 데이터베이스 서버로 전송되는 데이터의 볼륨을 감소시킨다.
5.2. 데이터베이스 서버의 CPU 사용량을 감소시킨다.
5.3. 스토리지 계층에서 디스크 액세스를 감소시킨다.
- 엑사데이터는 비엑사데이터 플랫폼에 비해 상당한 성능향상을 하드웨어와 소프트웨어 구성 요소 둘 모두를 사용하지만 소프트웨어 구성 요소의 성능 혜택이 훨씬 뛰어나다. 예를 들어
alter session set cell_offload_processiong=true;위 예제를 적용시켜 3.8억 건의 로우를 가진 테이블에 대해
select count(*) from kso.skew3 where col1 < 0;위와 같은 쿼리를 실행하면 Elapsed time이 약 51초에서 0.15초로 줄어든다. 이 차이점을 만든 것이 오프로딩을 통한 소프트웨어의 능력이다.
- 스마트 스캔 최적화: 스마트 스캔 최적화의 목표는 스캔 수행 중 데이터베이스 서버로 다시 전송해야 할 데이터 양을 줄이는 것이다. 주요 스마트 스캔 최적화는 세 가지가 있다.
1. 컬럼 프로젝션: 이것은 오직 관심 있는 컬럼만 반환함으로써 엑사데이터의 스토리지 계층과 데이터베이스 계층 사이에 전송되는 데이터의 양을 제한하는 기능이다. 만약 쿼리가 100개의 컬럼이 있는 테이블에서 다섯 개의 컬럼을 요청한다면, 불필요한 데이터를 스토리지에서 데이터베이스 서버로 반환하지 않고 제거할 수 있다. 해당 기능 외 Predicate 필터링과 스토리지 인덱스 기능은 WHERE절이 있을 때만 이루어진다.
alter session set "_serial_direct_read"=true;
alter session set cell_offload_processing=false;
select count(col1) from kso.skew3;
alter session set cell_offload_processing=true;
select count(col1) from kso.skew3;이렇게 예제를 구성할 경우 위 select문은 약 1분, 아래 select문은 약 30초의 elapsed time을 보여준다.
2. Predicate 필터링: 이것은 관심있는 로우만 데이터베이스 계층으로 반환하는 기능이다. iDB는 요청할 때 predicate 정보를 포함하기 때문에 데이터를 반환하기 전 스토리지 셀에서 표준 필터링 작업을 수행하여 완료된다. 비엑사데이터는 데이터베이스 서버에서 수행되어 결국 버려질 많은 레코드를 데이터베이스 계층으로 반환한다. 이 최적화는 데이터베이스 서버의 CPU 사용률을 일부 절감하기도 하며, 가장 큰 장점으로는 데이터 전송량의 감소이다.
--1
alter session set cell_offload_processing=false;
select count(pk_col) from kso.skew3;
--2
alter session set cell_offload_processing=true;
select count(pk_col) from kso.skew3;
--3 스토리지 인덱스 비활성
alter system set "_kcfis_storageidx_disabled"=true;
select count(pk_col) from kso.skew3 where col1 < 0;위 1번은 오프로딩을 중지하고 쿼리를 실행한 결과로 약 48초가 걸리고, 오프로딩 기능을 활성화하여 내부적으로 컬럼 프로젝션 기능에 의해 약 27초가 걸렸다. 그 후 3번에서 스토리지 인덱스를 해제하여 predicate 필터링에 의해 약 9초 정도로 단축했다.
3. 스토리지 인덱스: 스토리지 인덱스는 테이블당 최대 8개 컬럼까지 각각 1MB 디스크 스토리지 유닛마다 최대값과 최소값을 유지하는 스토리지 셀의 메모리 구조이다. 스토리지 인덱스의 목적은 스토리지 서버 자체에서 데이터를 읽어 들이는 시간을 제거하기 위함이다. 사전 필터같은 개념으로 스마트 스캔은 쿼리 predicate 정보를 스토리지 서버로 넘기며 스토리지 인덱스는 각 1MB 스토리지 영역당 값의 맵을 포함하고 있기에 일치하는 로우를 포함할 리 없는 영역은 읽어보지 않고도 제거할 수 있다. 디스크 I/O는 파티션 제거와 유사한 방식으로 제거된다. 즉, 파티션에 관심있는 레코드가 전혀 포함되어 있지 않다면 파티션 블록은 읽혀지지 않을 것이다. 다른 대부분의 스마트 스캔 최적화는 데이터베이스 서버로 전송되는 데이터의 양을 줄임으로써 성능을 개선하지만 스토리지 인덱스는 스토리지 서버의 디스크에서 데이터를 읽고 그 데이터를 필터링하는 데 걸리는 시간을 제거하여 성능을 개선한다.
- 심플 조인(블룸 필터)
조인 처리 또한 스토리지 계층으로 오프로드될 수 있다. 오프로드된 조인은 Bloom Filter를 생성하여 이루어진다. parallel query slave간의 트래픽을 감소시키기 위해 이를 사용한다. 또한 false positive를 반환할 수 있다는 점을 주의해야 한다. 즉, 요구된 결과 집합에 포함되지 말아야 할 로우가 때때로 블룸 필터를 통과한다.
--블룸 필터 오프로딩 활성화
alter session set "_bloom_predicate_pushdown_to_storage"=true;
- 함수 오프로딩
오라클 SQL 구현에는 내장 SQL 함수가 있으며 Single-row 함수와 Multi-row 함수 두 개의 주요 그룹으로 나뉜다.단일 로우 함수는 쿼리된 테이블의 모든 로우에 대한 단일 결과 로우를 반환한다.
1. 단일행 함수
1.1. 숫자 함수: SIN, COS, FLOOR, MOD, LOG, ...
1.2. 문자 함수: CHR, LPAD, REPLACE, TRIM, UPPER, LENGTH, ....
1.3. 날짜, 시간 함수: ADD_MONTHS, TO_CHAR, TRUNC, ...
1.4. 변환 함수: CAST, HEXTORAW, TO_CHAR, TO_DATE, ...
1.5. 단일행 함수는 모두 엑사데이터 스토리지에 오프로드될 수 있다.
2. 다중행 함수
2.1. 집계 함수: AVG, COUNT, SUM, ...
2.2 분석 함수: AVG, COUNT, DENSE_RANK, LAG, ...
2.3. 이들 함수는 어떤 것도 엑사데이터로 오프로드 될 수 없다. 이들 함수의 대부분이 개별 스토리지 셀이 가지고 있지 않은 전체 로우 집합을 액세스해야 하기 때문이다.
--특정 버전에서 어떤 함수가 오프로딩이 가능한 지 정의된 목록을 출력
select distinct name, version, offloadable
from V$SQLFN_METADATA
order by 1,2;
- 압축 / 압축해제
엑사데이터는 스마트 스캔 오퍼레이션 동안 HCC 포맷으로 저장된 데이터의 압축해제를 오프로드한다. 즉, 스마트 스캔으로 압축된 데이터에 접근할 때 필요한 컬럼은 스토리지 셀에서 압축해제 된다. 필터링은 데이터베이스 계층으로 반환될 데이터만 압축해제 된다. 모든 압축은 데이터베이스 계층에서만 이루어진다. 압축해제는 매우 CPU 집약적인 작업이기 때문에 스토리지 서버에서 이를 수행한다.
- 암호화 / 복호화
암복호화는 HCC 데이터의 압축과 해제와 매우 유사한 방식으로 처리된다. 암호화는 항상 데이터베이스 계층에서 처리되며 복호화는 스토리지 서버 혹은 데이터베이스 서버에서 처리될 수 있다. _CELL_OFFLOAD_DECRYPTION 파라미터가 압축을 먼저 한 후 HCC에 대한 암복호화에 대한 동작을 제어한다. _CELL_OFFLOAD_HYBRIDCOLUMNAR 히든 파라미터와와 이것을 FALSE로 설정하면 암호화된 데이터에 대한 스마트 스캔을 완전히 비활성화 하고 스토리지 계층에서 복호화도 비활성화 한다.