[기고] 엑사데이터 설계

엑사데이터에 대한 이해

엑사데이터(Exadata)의 특징으로 스마트스캔(Smart Scan), 인피니밴드 네트워크(InfiniBand Network), 스토리지인덱스(Storage Index), 셀 오프로딩(Cell Offloading), 플래시캐시(Flash Cache), HCC압축(Hybrid Columnar Compression) 기술을 들 수 있다.

자세한 기술 내용은 "[Oracle Exadata] 핵심 기술요소 Summary 1~4" 참고

스토리지 인덱스(Storage Index) : 데이터가 인덱스 범위에 속하지 않을 경우 해당 블록을 스캔하지 않도록 컬럼의 Min/Max 값을 Map 형태로 관리하여 Disk I/O를 줄임

셀오프로딩(Cell Offloading) : 기존 DB 서버에서 처리하던 질의 스토리지 서버에서 처리하는 개념으로, DB 서버의 부하를 줄이고 필요한 데이터만 DB 서버로 전송하여 I/O 성능 향상

HCC압축(Hybrid Columnar Compression) : 저장공간 및 I/O를 줄이기 위해 CU 단위로 컬럼을 묶어 압축

인피니밴드 네트워크(InfiniBand Network) : DB서버와 스토리지서버 사이의 데이터 처리 속도 향상

플래시 캐시(Flash Cache) : 디스크 I/O로 인한 액세스 병목을 줄이기 위해 스토리지 서버내의 플래시 캐시를 통해 속도 향상

스마트스캔(Smart Scan): DB서버와 스토리지서버 사이의 데이터 전송량을 최소화하기 위해 스토리지 인덱스와 셀오프로딩 기술을 이용하여 필요한 데이터만 읽고 전송하는 방식

그 중 스마트스캔이 무엇인지 아는 것이 가장 중요하다. 스마트스캔은 기존 오라클의 테이블 스캔, 인덱스 스캔처럼 데이터를 처리하는 방식이다. 엑사데이터는 스마트스캔, 테이블스캔, 인덱스스캔 할 수 있으며, 스마트스캔을 할 때 스토리지 인덱스와 셀 오프로딩 기술을 사용한다.

[표1] 엑세스 방식과 기술요소

우리가 흔히 엑사데이터는 스마트스캔을 한다고 알고 있지만, 실제로는 항상 스마트스캔 방식으로 데이터를 처리하는 것은 아니다. Full Scan과 Direct Path Read 조건을 충족해야 스마트스캔을 할 수 있다. 시스템이 DW 용이라면 대량 데이터를 처리하는 경우가 많으며, 이 경우 인덱스보다는 테이블을 스캔하여 처리하는 것이 효율적이다. 테이블스캔은 일반적인 테이블스캔과 스마트스캔으로 나눌 수 있고, 가급적이면 스마트스캔이 일어나도록 유도해야 한다. 만약 OLTP업무라면 스마트스캔 보다는 기존 오라클처럼 인덱스 스캔을 해야 한다.

[그림1] 엑사데이터 데이터 처리 개념

엑사데이터 물리 설계

엑사데이터에 대한 물리 설계는 어떻게 해야 될까? 결론부터 얘기하면 기존 오라클과 크게 다르진 않다(특별히 더 할 게 없다). 위 그림에서 스마트스캔이 일어날 때 우리가 할 수 있는 일이라곤 테이블 압축을 어떻게 하고 파티션을 어떻게 설계하느냐 정도이고, 나머지는 엑사의 하드웨어를 포함한 기술요소가 담당하게 된다. 기술적인 내용 보다는 엑사데이터를 사용하는 시스템의 업무 특성을 먼저 파악하는 것이 우선일 것이다.

[표2] 업무 특성에 따른 물리설계 및 기술요소

[표2]에서 보는 것처럼 DW 업무인 경우는 파티션 설계, HCC 압축방법에 대해 초첨을 맞춰야 한다. 대부분 테이블 스캔을 하게 될 것이고, 이 때 엑사 내부에서 스마트스캔, 스토리지 인덱스, 셀오프로드, 플래시 캐시와 같은 기술들이 활용될 것이다. OLTP의 경우는 기존 오라클처럼 인덱스 설계에 집중해야 한다.

파티션 설계

기본적으로 기존 오라클처럼 관리적인 측면(데이터 생명주기)과 성능적인 측면을 같이 고려하면 된다. 또한, 압축 및 스토리지 인덱스 효과로 인해 어느 정도 파티션 설계로 인한 성능향상을 대체 할 수 있으므로, 압축 후 테이블 크기 등을 기준으로 대상을 선정할 수 있다.

[표3] 파티션 설계 고려사항

관리적인 측면에서는 ILM(Imformation Lifecycle Management) 전략에 따라 데이터 생성과 소멸주기와 파티션이 일치하도록 파티션 키를 설계하는 것이 중요하다. 대량 데이터 처리를 위한 성능 관점에서 병렬처리에 대한 파티션 와이즈 조인을 염두에 두고 파티션 설계를 하면 좋을 것이다. OLTP 업무에서는 성능은 인덱스 설계를 통해 해결하는 것이 더 적절해 보이며, 파티션은 ILM 관리 목적으로 접근하는 것이 좋을 듯 하다. 서브 파티션 설계 시 인덱스 성능이 저하될 수 있으므로 좀 더 신중하게 서브 파티션 정책을 세워야 한다.

압축기법 설계

압축을 통해 저장 공간을 절약하고, 압축된 데이터를 스캔하므로 I/O 비용을 최소화 할 수 있다. 압축 기법을 선택할 때, 저장공간을 절약 할 지, 성능 향상을 목적으로 할 지 중요하다. 하지만 데이터 특성을 우선 고려해야 한다. 엑사데이터의 HCC 압축기법은 CU(Compress Unit)단위로 압축하여 압축율이 좋으나, 데이터 변경시 CU단위 Locking으로 인한 경합이 심하다. 또한, Direct Path Load 방식에서만 적용할 수 있는 한계가 있다.

[표4] HCC 압축 기법

자주 변경되는 테이블은 압축하지 않는 것이 좋고, 빈번하게 조회하는 테이블이라면 Query 모드 압축을 고려할 수 있다. 또한, 적재 위주나 백업용 테이블은 압축율이 우수한 Archive 모드 압축을 적용할 수 있다. 인덱스는 압축 전후 읽기, 쓰기 성능 차기가 크지 않으므로, 공간절약 차원에서 접근하는 것이 바람직해 보인다. 인덱스 압축 시 컬럼 값의 분포도에 따라 압축율이 달라지며, 컬럼 값이 Unique 할수록 오히려 인덱스 크기가 증가한다. Unique 인덱스는 반드시 일부 컬럼으로 압축하고, Non Unique 인덱스도 어떤 컬럼까지 압축에 참여시킬지 결정해야 한다. 모든 인덱스에 대한 데이터 분포를 조사할 수 없고, 노력에 비해 효과가 크지 않으므로 대규모 인덱스로 한정하여 압축기법을 적용하는 것도 좋은 방법이다.

인덱스 설계

기존처럼 데이터 엑세스 형태를 분석하여 설계하면 된다. 앞서 설명한 것처럼 인덱스 저장공간 절약과 성능 향상을 위해 크기가 큰 인덱스를 중심으로 압축기법을 세밀하게 적용한다.

[그림2] 인덱스 압축 효과

테이블 일반 설계

DW의 경우는 ODS, EDW, 마트 영역에 따라 테이블 특성이 다르다. ODS는 원천시스템과 동일한 구조를 가지며 빠르게 적재하고, 전체 데이터를 읽고 DW에 적재해야 한다는 특성이 있다. 스토리지 인덱스와 셀오프로딩 효과도 미비할 것이다. 테이블을 압축할 경우 Insert 시간은 2~3배 더 소요되나, 읽는 시간은 줄어들 것이다. 압축을 고려할 때, 읽기 성능과 공간절약을 목적으로 접근하는 것이 좋을 듯 하고, Query High나 Archive Low를 우선 고려할 수 있다.

EDW영역은 파티션 설계를 중심으로 하고, RAW 레벨 데이터를 처리하는 경우가 빈번하다면 인덱스 설계도 신경을 써야 한다. 또한 반정규화 설계 시, 테이블 압축효과로 인해 저장공간 부담이 적으므로 성능관점에서 적극 활용해도 좋을 듯 하다.

마트영역의 Fact 테이블을 설계할 때는 테이블당 스토리지 인덱스가 8개 컬럼까지 자동으로 만들어 지는 점을 고려하여 디멘전 컬럼 개수가 8개를 넘지 않도록 설계하는 것도 좋을 듯 한다.

글을 마치며

지금까지 엑사데이터에 대한 특징과 물리설계에 대해 나름대로 알고 있는 부분에 대해 설명했다. 기존 오라클 엔진에 새로운 엔진을 하나 더 추가한 개념으로 엑사데이터를 바라보며 이해하면 좀 더 쉬울 것이다. 새로운 엔진은 DB서버가 하던 일을 스토리지 서버가 일부 담당하도록 하드웨어 기술을 중심으로 구현되어 있으며, 새 엔진이 잘 작동하도록 우리가 할 수 있는 부분(물리설계)은 별로 없어 보인다. 설계보다는 SQL을 잘 작성하고 스마트스캔을 하는지 수행계획을 확인하는 것이 더 중요할지도 모르겠다.

OLTP 업무인 경우 인덱스를 설계할 때 성능보다는 공간절약 차원에서 압축 기법을 활용하고, 데이터 품질 문제를 방지할 수 있다면, 기존 오라클 보다 반정규화를 조금 더 해도 무방할 것이다.

여러분 생각은 어떤가? 엑사데이터에 대한 물리설계 방법이 많이 다른가?