[BigQuery] Partition 과 Cluster 에 대해 알아보고 적용하기 | LIM

✔️ 빅쿼리 Partition 이란?

빅쿼리 파티션이란 하나의 큰 테이블을 사용자가 지정한 column 에 맞추어 여러 스토리지 블록으로 쪼개놓은 것이다. 

파티션을 추가하는 경우 장점과 단점은 다음과 같다.

 

장점)

• Query 탐색범위를 줄인다. 
  • 빅쿼리는 쿼리가 데이터를 탐색하는 양만큼 비용을 부과한다.
  • 파티션이 걸린 경우 해당 파티션 범위만 탐색하기 때문에 비용이 덜 부과된다.
• Query 속도가 빨라진다.
  • 빅쿼리에서 데이터의 양에 따라 쿼리 소요 시간이 달라짐
  • 미리 조건에 맞추어 작은 테이블로 분할시켜놓았기 때문에 더 빠르게 결과가 나타난다.

단점)

• 테이블 간 join 비용이 증가한다.

 

🧐 Sharding(샤딩) 과의 차이는 무엇인가?

샤딩과 파티션 모두 데이터베이스를 여러개로 나누어 분산시키기 위한 기술 용어이다. 서비스 크기 증가에 따른 DB 크기 증가, 성능 이슈에 따라 나온 개념들이다. 

 

샤딩의 경우

• Horizontal Partitioning 이다. 
• 데이터의 row 개수를 기준으로 나누어 Partition 하는 방법이다. 
• 같은 테이블 스키마를 가진 데이터를 데이터베이스 여러개에 분산하여 저장하는 방법을 일컫는 용어이다. 
• Shard Key 를 생성해 테이블을 나눈다. Shard Key 를 생성하는 방법에는 다음과 같은 것들이 있다. 
  • Hash Sharding
  • Dynamic Sharding
  • Entity Group

 

파티셔닝의 경우

• Vertical Partitioning 이다.
• 테이블의 컬럼을 기준으로 데이터를 나눈다. 
• 자주 사용하는 컬럼을 분리하여 성능 향상을 꾀할 수 있다. 

 

빅쿼리에서 날짜/타임스탬프로 파티션을 나눈 Table 이 아닌 suffix 를 붙여서 테이블을 샤딩할 수도 있다.

하지만, 날짜/타임스탬프로 파티션을 나눈 테이블이 샤딩된 테이블보다 성능이 뛰어나다고 한다. 

 

그 이유는 샤딩 테이블을 만들 때 BigQuery 가 각 테이블의 스키마 및 메타데이터 복사본을 유지해야 하고, 각 쿼리 대상 테이블의 권한을 확인해야 하는데 이때 쿼리 오버헤드가 추가되고 쿼리 성능에 영향을 미치게 된다. 

 

 

🧐 파티션을 많이 나누면 좋을까?

파티션을 나누기를 수행하려면 BigQuery 가 파티션을 나누지 않은 테이블보다 더 많은 메타데이터를 유지해야 한다. 따라서 파티션의 수가 증가하면 유지할 메타데이터의 양도 증가한다. 현재 빅쿼리에선 기본적으로 다음과 같이 파티션 개수에 제한을 둔다. 물론 돈을 추가하면 더 늘릴 수 있다. -> fact check 필요

https://cloud.google.com/bigquery/quotas?hl=ko#partitioned_tables 

할당량 및 한도  |  BigQuery  |  Google Cloud

---

✔️ 빅쿼리 Clustering 이란?

Partition 이 데이터를 어디 구역에 저장할지를 정하는 부분이라면 클러스터링은 그 구역에서 순서에 맞게 정렬을 시켜둔 것이라고 볼 수 있다. 

 

BigQuery의 클러스터링된 테이블은 클러스터링된 열을 사용하여 사용자 정의 열 정렬 순서가 있는 테이블입니다. 클러스터링된 테이블을 사용하면 쿼리 성능을 높이고 쿼리 비용을 줄일 수 있습니다.BigQuery의 클러스터링된 테이블은 클러스터링된 열을 사용하여 사용자 정의 열 정렬 순서가 있는 테이블입니다. 클러스터링된 테이블을 사용하면 쿼리 성능을 높이고 쿼리 비용을 줄일 수 있습니다.

 

 



https://cloud.google.com/bigquery/docs/clustered-tables?hl=ko

 

즉, 파티션과 클러스터링을 같이 설정하면 파티션 내 데이터들을 미리 정렬시켜둠으로써 해당하는 데이터를 더 빨리 찾을 수 있게 되는 것 같다.

 

예를 들어서 위에 그림에서 Order_Date 별로 파티션이 나눠져 있다고 가정하고 US Country 만 가져온다고 가정하면 첫번째보다 두번째 테이블에서 쿼리 성능이 더 좋을 것이다. 

 

공식 문서에서 클러스터링 된 테이블을 쿼리하는 경우 쿼리 실행 전에 스캔할 스토리지 블록 수를 알 수 없기 때문에 쿼리 실행 전에 정확한 쿼리 비용 예상치는 제공되지 않는다고 한다. 최종 비용의 경우 쿼리 실행이 완료된 후 결정되며 스캔된 특정 스토리지 블록을 기반으로 한다. 

 

 

👩‍💻 클러스터 열 순서

클러스터링된 열의 순서는 쿼리 성능에 영향을 미친다. 클러스터링의 이점을 얻으려면 쿼리 필터 순서가 클러스터링된 열 순서와 일치해야 하며 최소한 클러스터링된 첫 번째 열이 포함되어야 한다. 

 

밑에 예시에서 Order table 은 현재 Order_Date, Country, Status 의 열 정렬 순서를 사용하여 클러스터링 한다. Order_Date, Country 는 클러스터가 적용된 걸 볼 수 있지만 Status 는 적용되지 않은 걸 볼 수 있다. 

 

따라서 첫번째 예시처럼 Order_Date, Country 로 필터를 하게 되면 쿼리가 Optimized 되나,

두번째 예시처럼 Country, Status 로 필터를 하게 되면 클러스터링에 Optimized 된 쿼리가 아니다. 

 

 

---

🧐 클러스터링된 테이블과 파티션을 나눈 테이블을 결합하자

테이블 클러스터링과 테이블 파티션 나누기를 결합하면 쿼리를 더욱 세부적으로 정렬할 수 있다. 

첫번째 테이블은 Partition, Cluster 모두 설정하지 않은 테이블이고, 두번째 테이블은 Cluster 만 적용된 테이블이다. 

세번째 테이블은 Partition 과 Cluster 모두 적용되어 각 블록으로 쪼개지고 그 블록 안에서의 Cluster 가 적용되게 된다. 

 

 

 

---

🚗 본격적으로 Partition 과 Cluster 를 적용시켜보자!

기존 테이블에서 데이터가 어느정도 쌓여있는 테이블을 가져와서 테스트해보았다. 너무 용량이 작은 테이블에 대해서는 partition 과 cluster 의 효과를 확인할 수 없으니 주의해야 한다. 

 

564GB 데이터 테이블로 테스트 진행

 

 

파티션 + 클러스터 적용 테이블

 

*slot count: slot_time_consumed / elapsed_time
-> 180개

 

 

파티션만 적용된 테이블

 

 

*slot count: slot_time_consumed / elapsed_time
-> 367개

 

💡 결론

Clustering 이 적용된 테이블이 그렇지 않은 테이블보다 slot time에서 70% 정도 감소된 걸 볼 수 있다. 

테이블의 특성을 잘 파악하여 적절히 파티션과 클러스터를 적용하는 것이 성능도 좋고 비용절감에도 효과가 있을 것이다.

 

 

 

📚참고

https://burning-dba.tistory.com/147

BigQuery - clustering 이야기

https://cloud.google.com/bigquery/docs/clustered-tables?hl=ko 

클러스터링된 테이블 소개  |  BigQuery  |  Google Cloud

https://cloud.google.com/bigquery/docs/creating-clustered-tables?hl=ko 

클러스터링된 테이블 만들기 및 사용  |  BigQuery  |  Google Cloud