결론부터 말하면 Amazon Redshift나 Snowflake에서 특정 컬럼 기준 ORDER BY 정렬은 일반 전통적인 OLTP DB(PostgreSQL, Aurora 등)보다 불리한 경우가 많습니다.

하지만 Redshift나 Snowflake에서도 특수한 처리를 하면 컬럼값 정렬 속도가오히려 매우 빠를 수 있습니다.

1. AWS Redshift가 정렬에 불리하다고 말하는 이유

핵심은 Redshift는 “정렬 기반 컬럼 저장형(Columna) DW” 이라는 점입니다.

Redshift 는 Columnar + MPP (Massively Parallel Processing) 구조입니다.

즉 데이터가 다음처럼 저장됩니다.

Node1
  block1
  block2

Node2
  block3
  block4

그리고 각 노드에서 병렬로 처리합니다.

문제는 ORDER BY 입니다.

SELECT *
FROM sales
ORDER BY purchase_date

이 경우 내부적으로 다음 과정이 필요합니다.

1) 각 노드에서 부분 정렬

2) 노드 간 데이터 shuffle

3) 최종 merge sort

즉

node1 sort
node2 sort
node3 sort

→ network shuffle
→ merge sort

그래서 전체 데이터 정렬은 비용이 큼

2. 반대로 OLTP DB는 왜 빠를까

예를 들어

• PostgreSQL
• Amazon Aurora

이 DB들은 보통 다음 구조입니다.

single node
row store
b-tree index

만약

ORDER BY purchase_date

이고 인덱스가 있다면

index scan → 이미 정렬된 상태

그래서 정렬 비용이 거의 없음

3. Redshift에서 정렬이 빠른 경우

Redshift는 SORT KEY가 있을 때 강력합니다.

예

CREATE TABLE sales
(
  user_id INT,
  purchase_date DATE,
  amount INT
)
SORTKEY(purchase_date);

이 경우 저장이 이렇게 됩니다.

block1   purchase_date 2023-01
block2   purchase_date 2023-02
block3   purchase_date 2023-03

그래서

SELECT *
FROM sales
ORDER BY purchase_date
LIMIT 100

이면

앞 block만 읽음

즉

엄청 빠름

4. 실제 Redshift에서 많이 하는 실수

SORTKEY 없는 ORDER BY

SELECT *
FROM large_table
ORDER BY created_at

→ 전체 데이터 sort

→ 매우 느림

LIMIT 없이 ORDER BY

ORDER BY created_at

→ 전체 dataset sort

SELECT *

columnar DB에서는

SELECT *

도 비용 큼

5. Redshift에서 정렬을 빠르게 하려면

(1) SORT KEY 설계

가장 중요

SORTKEY(event_time)
SORTKEY(user_id)

(2) LIMIT 사용

ORDER BY event_time
LIMIT 100

(3) DISTKEY 고려

노드 간 shuffle 줄이기

(4) pre-aggregation table

DW에서는 보통

raw table
→ aggregated table

6. 실제 현업에서 Redshift 정렬 전략

보통 이렇게 합니다.

fact table
SORTKEY(event_time)

query
ORDER BY event_time
LIMIT N

또는

materialized view
already sorted

정리하면 보통 이렇게 됩니다.

이번엔 Snowflake에 대해서 알아보겠습니다.

Snowflake 에서 ORDER BY 성능은 Amazon Redshift 와 비슷한 점도 있지만 구조적으로 조금 다릅니다.

결론부터 말하면:

Snowflake도 기본적으로 정렬 쿼리는 OLTP DB보다 불리하지만, micro-partition pruning과 clustering 덕분에 상황에 따라 Redshift보다 유연합니다.

아래 구조적으로 설명하겠습니다.

7. Snowflake의 저장 구조

Snowflake는 Redshift처럼 columnar DW이지만 저장 방식이 다릅니다.

Redshift

node
 └ block

Snowflake

micro-partition (약 50~500MB)

예

partition 1   purchase_date 2023-01
partition 2   purchase_date 2023-02
partition 3   purchase_date 2023-03

각 micro-partition에는 min/max metadata가 존재합니다.

min_date
max_date
distinct values

그래서 쿼리 시

partition pruning

이 발생합니다.

8. Snowflake에서 ORDER BY가 수행되는 방식

예

SELECT *
FROM sales
ORDER BY purchase_date

실행 과정

1 scan micro-partitions
2 distributed partial sort
3 final merge sort

즉 구조적으로는

worker sort
worker sort
worker sort
↓
merge sort

이는 Redshift와 비슷합니다.

그래서

전체 테이블 ORDER BY는 Snowflake도 비용이 큼

9. 하지만 Redshift와 큰 차이

Redshift는 SORT KEY 기반 물리 정렬

Snowflake는 자동 clustering + pruning

차이

10. Snowflake에서 ORDER BY가 빨라지는 경우

(1) LIMIT 존재

SELECT *
FROM sales
ORDER BY purchase_date
LIMIT 100

이 경우

top-k optimization

이 작동합니다.

그래서

전체 sort 필요 없음

(2) clustering key 존재

ALTER TABLE sales
CLUSTER BY (purchase_date);

그러면 micro-partition이

2023-01
2023-02
2023-03

식으로 정렬됩니다.

(3) WHERE + ORDER BY

예

SELECT *
FROM sales
WHERE purchase_date >= '2024-01-01'
ORDER BY purchase_date

이 경우

partition pruning
→ sort 대상 데이터 감소

11. 실제 성능 차이(Snowflake vs. Redshift)

대략적인 경향

12. Snowflake가 Redshift보다 유리한 점

Snowflake는

micro-partition metadata

덕분에 다음이 강합니다.

WHERE + ORDER BY

예

SELECT *
FROM logs
WHERE event_date >= '2025-01-01'
ORDER BY event_date
LIMIT 100

Snowflake는

partition pruning
→ 90% partition skip

이 가능함.

13. 전체적인 정렬 성능 비교

14. 실제 데이터 플랫폼 아키텍처 관점

DW 시스템에서는 보통 이렇게 사용됩니다.

Aurora
→ OLTP 조회

Redshift / Snowflake
→ 분석

그래서

ORDER BY 전체 정렬

같은 쿼리는

DW에서는 보통

BI tool
top N
aggregation

형태로 사용됩니다.

참고,

대형 DW에서 가장 비싼 쿼리 TOP3는 보통 이것입니다.

1 ORDER BY
2 DISTINCT
3 global join shuffle