큰 테이블에서 느린 집계 쿼리를 어떻게 최적화하나요?

Question

IT Interview Practice · Accepted Answer

느린 집계를 최적화하려면 먼저 **결과의 의미와 시간을 쓰는 연산**을 파악합니다. 집계는 여러 행을 판매자별 매출 같은 요약으로 묶습니다. 비용은 읽고 결합할 데이터 양에 달려 있습니다.

지난달 매출 대시보드를 예로 들어, 쿼리를 개선할지, 미리 계산한 요약을 저장할지, 보고 작업을 다른 곳으로 옮길지 판단합니다.

## 1. 빠르게 만들기 전에 답이 맞는지 확인합니다

매출이 결제된 주문인지 생성된 주문인지, 환불을 어떻게 반영하는지, 어떤 통화를 포함하는지 명확히 합니다. 대시보드의 최신성 요구도 확인합니다. 이 선택에 따라 쿼리와 가능한 최적화가 달라집니다.

흔한 실수는 결제를 여러 주문 항목과 조인한 다음 결제 금액을 합산하는 것입니다.

```text
[Payment: 100] -> [Join with 3 items] -> [100, 100, 100]
                                               |
                                          [SUM = 300]
```

숫자는 예시입니다. 결제가 중복됐으므로 빨라져도 틀린 합계를 빨리 반환할 뿐입니다. 성능을 평가하기 전에 의도한 업무 단위로 집계하거나 조인을 수정합니다.

## 2. 실행 중 비싼 부분을 찾습니다

실행 계획은 결과를 얻기 위한 연산을 보여 줍니다. 인덱스를 하나 더 만들면 된다고 생각하지 말고, 비싼 단계와 입력 크기를 확인합니다.

| 관찰 | 조사할 질문 |
| --- | --- |
| 불필요한 행을 많이 읽음 | 필터나 파티션 제외로 줄일 수 있는가? |
| 실제 행 수와 추정치가 크게 다름 | 통계가 이 데이터를 잘 나타내는가? |
| 조인이 작업을 여러 번 반복 | 입력이 너무 크거나 접근 경로가 부적절한가? |
| 그룹화나 정렬이 임시 데이터를 디스크에 기록 | 메모리 한도를 바꾸기 전에 입력을 줄일 수 있는가? |

PostgreSQL의 EXPLAIN (ANALYZE, BUFFERS)는 쿼리를 실제로 실행하고 실행 정보를 제공합니다. 비싼 조사는 통제된 환경이나 명시적으로 정한 운영 부하 한도 안에서 수행합니다. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. 현재 데이터베이스의 작업량을 줄입니다

대시보드에 필요한 달과 열만 선택합니다. 실행 계획이 무관한 파티션을 실제로 건너뛰는지, 조인이 요약에 필요 없는 데이터를 가져오는지 확인합니다.

인덱스는 충분한 읽기를 피할 때 유용합니다. 보고서가 대부분의 행을 필요로 하면 순차 스캔이 적절할 수 있습니다. 인덱스 사용 여부만 보지 말고 실행 계획과 측정 비용으로 판단합니다.

정렬이 디스크로 넘친다면 입력을 줄여 해결할 수 있습니다. 모든 쿼리의 메모리를 늘리면 동시 보고서 실행 때 RAM이 고갈될 수 있습니다. 실제를 대표하는 동시 부하로 시험합니다.

## 4. 결과를 미리 준비할지 결정합니다

여러 사용자가 같은 합계를 요청하고 지연을 허용한다면 원시 주문을 매번 스캔하는 것은 낭비입니다. 날짜, 판매자, 통화별 합계를 요약 테이블에 저장하고 대시보드는 작은 결과를 합칠 수 있습니다.

```text
[Orders] -> [Scheduled / incremental calculation]
                              |
                       [Daily summaries] -> [Dashboard]
```

공통 계산을 요청마다 하지 않고 한 번 수행하는 것이 이점입니다. 구체화된 뷰도 쿼리 결과를 저장하는 방식이며 자체 갱신 동작이 있습니다.

이 절약에는 책임이 따릅니다.

- 갱신 주기를 정하고 사용자에게 필요한 최신성 정보를 표시합니다.
- 환불, 늦은 주문, 수정을 중복 계산 없이 반영합니다.
- 반복 처리를 안전하게 하고 요약을 재구축할 방법을 유지합니다.
- 평균을 결합할 때 합계와 개수를 저장합니다. 평균의 평균은 틀릴 수 있습니다.

이 대시보드에서는 최신성과 수정 규칙이 첫 단계의 요구를 충족할 때만 사전 요약이 후보가 됩니다.

## 5. 측정이 필요성을 보여 주면 보고를 분리합니다

넓은 분석 스캔이 계속 비싸고 구매를 방해한다면 해당 부하에 적합한 분석 저장소를 검토합니다. 동기화 지연, 복구, 추가 시스템 운영 비용도 포함합니다.

읽기 복제본은 보고 부하를 격리할 수 있지만 같은 쿼리는 거기서도 비쌀 수 있습니다. 분리는 비용을 지불하는 장소를 바꾸며 반드시 없애지는 않습니다.

각 변경을 신뢰할 수 있는 결과와 동일한 시험 부하로 비교합니다. 응답 시간, 자원, 최신성, 쓰기 영향을 확인합니다.

**기억할 점:** 올바른 결과 → 측정한 병목 → 불필요한 작업 축소 → 적절하면 사전 요약 → 여전히 필요하면 분석 분리.

관찰	조사할 질문
불필요한 행을 많이 읽음	필터나 파티션 제외로 줄일 수 있는가?
실제 행 수와 추정치가 크게 다름	통계가 이 데이터를 잘 나타내는가?
조인이 작업을 여러 번 반복	입력이 너무 크거나 접근 경로가 부적절한가?
그룹화나 정렬이 임시 데이터를 디스크에 기록	메모리 한도를 바꾸기 전에 입력을 줄일 수 있는가?

1. 빠르게 만들기 전에 답이 맞는지 확인합니다

2. 실행 중 비싼 부분을 찾습니다

3. 현재 데이터베이스의 작업량을 줄입니다

4. 결과를 미리 준비할지 결정합니다

5. 측정이 필요성을 보여 주면 보고를 분리합니다

관련 질문