Skip to Content
Data EngineeringPhoenix ROW_TIMESTAMP의 시간 범위 조회 최적화
📊 Data Engineering2017년 5월 25일

Phoenix ROW_TIMESTAMP의 시간 범위 조회 최적화

#phoenix#hbase#time-series#data-engineering#flamingo

Phoenix의 시계열 조회 자료를 찾아보며 정리했던 ROW_TIMESTAMP 기능입니다. 아래 성능 수치는 제가 운영 환경에서 테스트한 결과가 아니라, Samarth Jain이 2015년 Apache Phoenix 공식 블로그에 공개한 실험 결과입니다.

원문은 New optimization for time series data in Apache Phoenix 4.6 입니다.

시간 컬럼과 HBase 타임스탬프 연결

ROW_TIMESTAMP는 Phoenix 기본 키의 시간 값을 HBase의 셀 타임스탬프와 연결합니다. 해당 컬럼을 시간 범위로 조회하면 HBase가 파일의 시간 범위를 이용해 불필요한 Store File을 건너뛸 수 있습니다.

Phoenix 공식 문서 에 따르면 테이블당 하나의 기본 키 컬럼에만 지정할 수 있습니다. 지원하는 시간·숫자 타입과 NULL·음수 제한도 확인해야 합니다.

테이블 정의 예시

다음은 기능을 설명하기 위한 간단한 예시입니다.

sql
CREATE TABLE METRIC_EVENTS ( HOST VARCHAR NOT NULL, EVENT_TIME TIMESTAMP NOT NULL, METRIC_VALUE DOUBLE, CONSTRAINT PK PRIMARY KEY (HOST, EVENT_TIME ROW_TIMESTAMP) );

시간 조건을 EVENT_TIME에 적용하면 일반 기본 키 최적화와 함께 scan의 시간 범위를 사용할 수 있습니다. 실제 효과는 파일 구성과 데이터 분포에 따라 달라집니다.

공식 블로그의 성능 비교

원문은 약 5억 건을 초기 적재한 두 테이블을 비교했습니다. 하나는 ROW_TIMESTAMP를 사용하고 다른 하나는 사용하지 않았습니다. 이후 쓰기가 계속 발생하는 상황에서 아직 Major Compaction되지 않은 최근 데이터를 조회한 결과입니다.

조회 범위적용미적용
최근 1분200ms4,000ms
최근 15분700ms130,000ms
최근 1시간2,100ms500,000ms
적재된 시간 범위 밖100ms340,000ms

이 결과는 당시 실험의 조건에서 나온 값입니다. 다른 환경에서도 같은 차이가 난다는 기준으로 사용할 수는 없습니다.

Major Compaction 이후의 차이

원문은 파일이 합쳐져 더 넓은 시간 범위를 담게 되면 파일을 건너뛰는 효과가 줄어든다고 설명합니다. 실험에서는 이미 Major Compaction된 데이터에 대해 두 테이블의 성능이 같았습니다.

따라서 최근 구간의 조회가 많다는 이유만으로 적용을 결정하기보다, 실제 HFile의 시간 범위와 compaction 전후 조회를 함께 확인해야 합니다.

Last updated on