> ## Content Index > Fetch the complete content index at: https://www.mekeywhydoesmatter.com/llms.txt > Use this file to discover other available public pages before exploring further. # [DATA] 3. AWS Redshift와 Snowflake에서의 컬럼 데이터 정렬 속도에 관하여 - URL: https://www.mekeywhydoesmatter.com/data-3-aws-redshiftwa-snowflakeeseoyi-keolreom-deiteo-jeongryeol-sogdoe-gwanhayeo/ - Published: 2026-03-04T13:49:32.000Z - Updated: 2026-03-04T13:49:32.000Z - Author: mekey - Tags: Data 결론부터 말하면 **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 ``` --- 정리하면 보통 이렇게 됩니다. | **작업** | **Aurora** | **Redshift** | | ------------------- | ----------- | ------------ | | 특정 row 조회 | Aurora 압승 | | | 대량 aggregation | Redshift 압승 | | | ORDER BY (no index) | Aurora | | | ORDER BY (sortkey) | Redshift | | --- ## 이번엔 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** 차이 | **항목** | **Redshift** | **Snowflake** | | ------------------ | ------------ | ------------- | | 데이터 정렬 | SORTKEY | clustering | | 자동 정렬 | vacuum 필요 | 자동 | | partition metadata | 제한적 | 매우 강력 | --- # **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)** 대략적인 경향 | **쿼리** | **Snowflake** | **Redshift** | | ---------------- | ------------- | ------------ | | ORDER BY 전체 | 느림 | 느림 | | ORDER BY + LIMIT | 빠름 | 빠름 | | ORDER BY + 필터 | 빠름 | 중간 | | SORTKEY 정렬 | \- | 매우 빠름 | --- # **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\. 전체적인 정렬 성능 비교** | **시스템** | **특징** | | ---------- | ----------------------- | | PostgreSQL | index 기반 정렬 | | Aurora | index scan | | Redshift | sortkey | | Snowflake | micro-partition pruning | --- # **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 ```