Redshift의 테이블을 만들 때 가려운 곳을 정리해 보았습니다.

3667 단어 redshiftAWS
Redshift의 테이블 작성으로 자주 잊는 포인트를 정리해 두겠습니다.
주로 작성할 때의 포인트만으로, 데이터 설계에 관한 것은 쓰지 않습니다.

레코드 작성 시간



사용할지 여부는 모르겠지만, 비교적 달라질 수 있는 컬럼이라고 생각하기 때문에 자주(잘) 붙입니다.
다만, 자주 있는 RDB로 설정한다 default current_timestamp 라든지는 사용할 수 없기 때문에 주의.

우선 이런 느낌으로 설정해 둡시다.
create table hoge (
  // なんか他のカラム
  created_time timestamp encode DELTA default sysdate
)

정렬 키, 분산 키



Redshift의 퍼포먼스를 높이기 위해서, 무엇이라도 제일 중요하다고 할 수 있는 곳.
  • 정렬 키 : 레코드 정렬 순서
  • 분산 키 : 여러 노드에 분산하기위한 키

  • 정렬 키 설정



    특히 이유가 없으면 created_time이라면 좋다고 생각합니다.
    왜냐하면 새로운 데이터만 처리하고 싶을 때 빨리 select 할 수 있기 때문입니다.
    단, 특별히 무거운 join 등을 할 때는 다시 생각하는 것이 좋습니다.
    복수 설정할 수 있습니다만, 소트 키를 복수 설정할 뿐이므로, 조건이 없으면 하나로 OK입니다.

    복수 설정할 때는 복합 소트 키라고 합니다만, 너무 소트 키를 너무 늘리면 테이블의 디스크 용량이 늘어납니다. 그래서 제대로 정렬해야 할 것을 설정해 둡시다.
    create table hoge (
      // カラム
    )
    sortkey(created_time)
    

    분산 키 설정



    유저의 로그등이면 유저 ID라든지 분산하기 쉬운 것이 좋다.
    이상을 설정하면 노드마다 데이터 양의 편향을 할 수 있습니다.
    물론 특별히 무거운 조인 등을 할 때는 다시 생각하는 것이 좋습니다.
    create table hoge (
      // カラム
    )
    distkey(created_time)
    

    ※덧붙여서, distkey는 sortkey보다 먼저 설정하지 않으면 쿼리 에러가 되기도 합니다

    JOIN 할 것을 알고있을 때



    Redshift의 JOIN 처리는 내부적으로 3종류 있습니다.
    자세한 내용은 여기 (공식 도움말)을 참조하십시오. 다만, 대체로 아래와 같은 기억 방법으로 좋다고 생각합니다.
    1노드로 운용하고 있거나 하면, 가끔 Merge Join보다 Hash Join이 빠를 때도 있습니다만, 대체로의 경우 Merge Join이 빠릅니다.
  • Nested Loop Join: 야베 녀석
  • Hash Join: 일반 녀석
  • Merge Join: 빠른 녀석

  • 그러나 Merge Join은 상당히 엄격합니다.
  • 조인 할 열이 정렬 키와 분산 키 모두에 설정됩니다.
  • 두 테이블이 각각 80 % 이상 정렬되었습니다

  • 이 Join을 하려고 하면 테이블을 만들 때 노리고 만들 수밖에 없습니다.

    압축 형식



    압축 형식에 따라 디스크 사용량, 퍼포먼스가 상당히 바뀌므로, 설정할 수 있습니다.
    단지 가득 ​​있어 잘 모르기 때문에, 가볍게 정리해 둡니다.



    물론, 찌르면 더 효율적으로 압축 방식을 선택할 수도 있지만, 어디까지나 잡하게 정리하고 있습니다.
    (최소한 이 정도 판단 조건에 넣는 편이 좋다, 라면 가르쳐 주세요, 갱신합니다)

    설정 방법
    create table hoge (
      // なんかカラム
      columnName varchar(255) encode lzo,
      // なんかカラム
    )
    

    이제 행복한 Redshift 생활을 보내자.

    좋은 웹페이지 즐겨찾기