먼저 저장량, 요청 트래픽, 한 레코드의 갱신 중 무엇이 불균형한지 파악합니다. 과부하 작업을 옮길 수 있을 때만 서버 추가가 도움이 됩니다.
주문을 판매자 ID로 분할한다고 합시다. 대부분 작지만 한 판매자가 큰 캠페인을 시작합니다. 그 샤드만 과부하이고 나머지는 한산합니다. 처리 능력보다 많은 일이 몰리는 핫 파티션입니다.
1. 키 변경 전에 불균형을 측정합니다
샤드별 데이터 크기, 요청률, 지연, CPU나 디스크 압박을 비교합니다. 과부하 샤드를 판매자와 작업별로 나눠 봅니다. 오래된 데이터를 담은 큰 샤드는 한가할 수 있고, 작은 샤드는 인기 항목의 반복 갱신으로 압도될 수 있습니다.
캠페인 부하가 상품 상세 읽기인지, 독립 주문 다수 생성인지, 같은 재고 레코드의 반복 변경인지 확인합니다. 세 경우는 처방이 다릅니다.
2. 현재 분산으로도 편향이 남는 이유를 이해합니다
샤드 키는 레코드 위치를 정합니다. 판매자 ID를 해시하면 서로 다른 판매자를 분산할 수 있지만 같은 키의 주문은 같은 배치 규칙을 따릅니다. 해싱만으로 한 판매자의 부하가 자동 분리되지는 않습니다.