Phoenix - Salted Tables

HBase의 sequential write(순차적 쓰기)에서 row key 가 만약 일정하게 증가하게 되면, region server 에 hotspotting (region 서버 한 곳에 집중적으로 쓰기 작업이 이루어지는 경우) 을 유발시킬 수 있다.

Row key 를 salting 함으로써 이러한 문제점을 완화 시킬 수 있다.

Phoenix 는 특정 table에 salting byte를 이용하여 row key 를 salting 하는 방법을 제공한다.

Table 생성 시 “SALT_BUCKETS” 이라는 속성에 값(1~256)을 할당하여 사용할 수 있따.

CREATE TABLE table (a_key VARCHAR PRIMARY KEY, a_col VARCHAR) SALT_BUCKETS = 20;

Salted table 을 사용할 때, 몇가지 알아야 할 주의사항과 차이점이 있다.

Sequential Scan

• Salting table 은 data 를 순차적으로 저장하지 않기 때문에, 순차적 스캔이 반환하는 데이터들이 정렬되어 있지 않을 수 있음
• 현재 순차적 스캔을 강제하는 (예를 들면 LIMIT 같은) 절(clause) 들은 일반 테이블과 다른 결과를 반환할 수 있음

Splitting

• table 의 split point 가 명시되어 있지 않다면, salted table 은 region server 들간의 부하를 분산하기 위해 salt byte 영역을 기반으로 미리 split(Pre-split) 함
• 사용자가 split point 를 직접 제공한다면, 사용자가 제공하는 split point 에 salt byte 를 포함시켜야 함

Row Key Ordrering

• Pre-split 은 region server 안에 데이터들이 모두 같은 salt byte 로 시작하는 것음 보장하기 때문에 정렬되어 저장됨
• 모든 region server 에 병렬로  스캔을 실행할 때, 클라이언트 쪽의 병합 정렬을 수행하기 위해 이 속성을 이용할 수 있음
• 일반 테이블에서는 여전히 스캔의 결과가 순차적으로 반환될 것임

• Rowkey 정렬 스캔은 phoenix.query.rowKeyOrderSaltedTable (hbase-site.xml) 을  true 설정함으로써 활성화 시킬 수 있음
• Salted table 에서는 사용자가 명시한 split point 를 허락하지 않음
  • 각각의 bucket 이 같은 salt byte 를 가진 데이터만을 포함하는 것을 보장하기 위해서
• phoenix.query.rowKeyOrderSaltedTable 속성이 활성화 되어 있다면, salted table은 일반 테이블 처럼 동작하고 스캔에 대해 rowkey 로 정렬하여 데이터를 반환

Performance

• Pre-split 된 Salted table 을 사용하여 모든 region server 들에게 쓰기 작업 부하를 균등하게 분산하여 쓰기 성능을 향상 시킴
• non-salted table 에 비해 80% 까지 성능향상을 달성
• Salted table 은 균일한 데이터 분산을 통해 읽기 작업에도 이득이 있음

참조 : https://phoenix.apache.org/salted.html