Requirements
- 6억건 이상의 데이터를 매시간 insert하고 select 퍼포먼스도 유지해야 함(insert 시간은 < 5분)
- No SQL은 지양하고 RDB에서 구현되어야 함(데이터 정합성이 매우 중요한 pricing 데이터)
- dimension 확장으로 인한 record counts를 효과적으로 압축해야 함
클러스터링
- 특정 dimension들의 value가 같은 경우 grouping하고 grouping key를 부여
- metric을 적용하기 위해 dimension condition을 조회하는 경우 매핑 테이블과 엮여서 조회
- 어떤 dimension들의 조합이 압축은 잘 되면서 확장성을 가지는지 테스트
클러스터링 방식의 특징
- dimension들의 조합이 과해지면 debug가 어려워지고, 클러스터링이 된 테이블 자체의 크기가 커질 수 있음(결국 Load 부하를 분산하는 형태이기 때문)
- dimension들이 모두 significant하게 작용해 dimension별 metric차이가 심할 경우, 효과가 떨어짐(궁극적으로는 특정 metric을 targeting해서 grouping 하기 때문. 정보량에서 손해를 본다는 cost가 전제되나 이것이 무시할 수 있을 정도임이 합의 되어야 함.)
'ETL 관련' 카테고리의 다른 글
| S3 업로드 방식 비교 (0) | 2025.03.05 |
|---|---|
| [생각정리] load balancer가 있는 상황에서 output 처리 (0) | 2023.09.13 |
| df dropna와 NaN replace[groupby시 유의점] (0) | 2023.07.04 |
| 데이터 병합 시 유의해야 할 data type 문제 (0) | 2023.07.03 |
| Druid에 insert와 delete 하는 방식 (0) | 2023.02.15 |