[AWS] Redshift의 특징들. 다른 DB와 뭐가 다른가?
Redshift는 AWS의 MPP(Massive Parallel Processing) Database이다. PostgreSQL을 기반으로 하지만 PostgreSQL과 다르게 구현된 특징과 기능들도 있다.
AWS Document 기반으로 Redshift의 특성에 대해서 정리해보았다.
Redshift의 가장 큰 특징 두가지
1. Massive Parallel Processing
다수의 컴퓨팅 노드가 각 노드의 코어마다 전체 데이터를 분할하여 동일하게 컴파일된 쿼리 세그먼트를 실행.
데이터를 병렬로 처리 할 수 있도록 테이블의 행을 계산 노드에 배포.
각 테이블마다 적절한 분산 키를 선택하면 데이터 분산을 최적화할 수 있다.
더 알아보기
https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/c_loading-data-best-practices.html
https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/c_best-practices-best-dist-key.html
2. Columnar data storage
데이터베이스 테이블 정보를 열 기반 방식으로 저장하기 때문에 디스크 I/O 요청 수나 디스크에서 로드하는 데이터 크기를 감소시킬 수 있다.
더 알아보기https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/c_columnar_storage_disk_mem_mgmnt.html
https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/c_best-practices-sort-key.html
Redshift의 특징들
Cluster
Redshift는 클러스터로 구성 되어 있으며 리더 노드와 하나 이상의 컴퓨팅 노드로 구성되어 있다. 외부 어플리케이션은 리더 노드와 통신한다.
- OLTP 기능
데이터 삽입 및 삭제와 같은 온라인 트랜잭션(OLTP) 기능을 포함하여 일반적인 RDBMS와 동일한 기능을 제공하기는 하지만, 특히 매우 큰 데이터 세트의 분석을 위해 최적화됨. - 데이터 압축
디스크 I/O를 떨어뜨림으로써 쿼리 성능이 향상되는 효과.
쿼리를 실행하면 압축된 데이터를 메모리로 읽어온 후 쿼리 실행 도중 압축이 해제
Redshift가 PostgreSQL과 다른 점
보조인덱스 없음
보조 인덱스 작업 같이 소규모 OLTP 처리에 적합한 PostgreSQL 기능은 성능 개선을 위해 제외
지원하지 않는 쿼리 형식
- ALTER COLUMN 타입의 명령 불가
- ADD COLUMN은 각 ALTER TABLE 명령 당 한개 컬럼만 가능
- INSERT, UPDATE, DELETE 사용 시 WITH clause를 지원하지 않음
COPY
COPY 명령은 테이블을 로드하는 가장 효율적인 방법.
INSERT 명령을 사용하여 데이터를 테이블에 추가할 수도 있지만 COPY를 사용하는 것보다 효율은 훨씬 떨어진다
COPY table-name [ column-list ]
FROM data_source authorization [ [ FORMAT ] [ AS ] data_format ] [ parameter [ argument ] [, ... ] ]Vacuum
PostgreSQL에서는 기본적으로 VACUUM 작업이 공간을 재사용할 수 있도록 회수하는 데 그치는 반면 Amazon Redshift에서는 VACUUM FULL이 기본 VACUUM 작업으로서 디스크 공간을 회수한 후 모든 행을 재정렬
OLTP — OLAP 차이
OLAP과 OLTP DB는 그 목적과 활용방식이 확연히 다르다.
OLTP DB는 주로 서비스 운영에 활용되는 데이터베이스이며 row 단위 update와 insert가 잦은 서비스 형태로 사용된다.
OLAP DB는 상대적으로 큰 규모의 데이터에 분석적인 쿼리, aggregation을 위한 무거운 쿼리가 요구된다.
Redshift DB는 OLAP 목적으로 사용된다.
Redshift — Athena 차이
Athena는 serverless 서비스로 S3의 데이터셋에 바로 쿼리를 가능하게 해준다. 쿼리 엔진은 Presto가 기반이며 DDL statement로 HiveQL을 사용한다.
이러한 Athena의 특성 상 주로 S3의 데이터에 Glue 스키마만 생성해주고, 간편하게 ad-hoc 목적, EDA(Exploratory Data Analysis) 목적으로 사용하기에 적절하다. 그러나 대용량 쿼리나 정기적 배치 처리에는 추천하지 않는다. Athena의 리소스를 사용자가 독점하는 방식이 아니라 Region별로 리소스를 공유하므로, 트래픽이 몰리는 시간대에 메모리 부족 오류 등이 발생하기도 한다. 이러한 이유로 정기 배치에 사용하던 Athena 쿼리를 모두 Spark로 교체하는 작업을 하기도 했다.
Redshift의 경우, Structured Data를 통한 BI 제공, 배치 처리 등에 적합하다.
개인적인 의견으로는, S3나 HDFS 등의 file system과 함께 Spark나 Hive 등의 Hadoop 클러스터를 운영하는 경우 굳이 Redshift를 병행 운영할 필요성을 느끼지 못하고 있다. (따라서 팀에서 기존에 병행 운영하던 Redshift는 Fade out 예정이다.)
그러나 그렇다고 해서 항상 빅데이터 클러스터가 Redshift보다 나은 것은 당연히 아니다. 이를 별도로 운용하기 위해서는 구축이나 운영에 훨씬 더 많은 리소스가 소요된다.
각자가 가진 엔지니어링 리소스와 목적에 따라 Redshift와 같은 MPP DB로 활용는 것도 데이터 분석 목적의 데이터 레이크로써는 충분히 좋은 대안이 될 듯 하다.
향후 Redshift에 Aqua라는 새로운 layer가 추가될 예정이다.
Redshift with AQUA
AWS에서 Advanced Query Accelerator (AQUA)를 소개하고 있길래 덧붙여보았다. 2020 5월은 아직 preview만 가능한 상태. 분산 하드웨어 가속 캐쉬(distributed and hardware-accelerated cache) 레이어를 S3 와 컴퓨팅 클러스터 사이에 붙인 구조이다.
데이터웨어하우스가 규모와 기술이 발전하는동안, bottleneck으로 작동한 것은 network bandwidth이다. 비단 네트워크 뿐만 아니라, 2012년 이래 스토리지는 SSD의 발전을 통해 12배 이상 빨라지는 동안 CPU와 DRAM은 2배 정도 빨라지는데 그쳤다.
AQUA는 이러한 두 문제를 해결하기 위해, 스토리지와 컴퓨팅노드 사이에 AQUA Layer를 두고 데이터를 처리하도록 한다.
필터링과 집계등 데이터 집약(data intensive)적인 처리를 Storage layer와 가까운 AQUA에서 처리하고 compute cluster로 보냄으로써 데이터 전송량을 줄인다. Let’s see!
